aboutsummaryrefslogtreecommitdiffstats
path: root/gcc-4.4.3/libstdc++-v3/doc/html
diff options
context:
space:
mode:
Diffstat (limited to 'gcc-4.4.3/libstdc++-v3/doc/html')
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/README3
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/api.html54
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/bk02.html3
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/bk03.html3
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html19718
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-closed.html14016
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-defects.html29778
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/PythonPoweredSmall.gifbin361 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/acks.html65
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.pngbin21668 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.svg491
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_traits.html170
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_design.html46
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_examples.html151
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_performance_tests.html345
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_regression_tests.html93
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_tests.html24
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/associative_container_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/balls_and_bins.pngbin10139 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_table.html436
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_invalidation_guarantee.html26
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree.html660
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_assoc_container_const_node_iterator.html383
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_heap_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_gcc.pngbin5357 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_local.pngbin6710 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_msvc.pngbin5373 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binomial_heap_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html532
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_gcc.pngbin7074 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_local.pngbin8534 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_msvc.pngbin7235 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_gcc.pngbin6811 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_local.pngbin8445 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_msvc.pngbin7230 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_gcc.pngbin7636 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_local.pngbin9396 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_msvc.pngbin6840 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_table.html724
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_gcc.pngbin7355 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_local.pngbin9557 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_msvc.pngbin7572 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/checked_by_tidy.gifbin1367 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/concepts.html118
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/contact.html22
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_base.html1063
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.pngbin11884 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.svg418
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_tag.html24
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/counter_lu_policy.html259
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/design.html96
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/different_underlying_dss.pngbin31858 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mask_range_hashing.html167
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mod_range_hashing.html144
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/disclaimer.html34
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ds_gen.html344
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_1.pngbin16350 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_2.pngbin18206 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_3.pngbin5612 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/examples.html24
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/exceptions.html46
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_gcc.pngbin6194 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_local.pngbin7916 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_msvc.pngbin6140 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_gcc.pngbin6110 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_local.pngbin7570 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_msvc.pngbin6314 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_gcc.pngbin6763 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_local.pngbin8499 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_msvc.pngbin6721 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_table.html891
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_based_containers.html835
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_exponential_size_policy.html183
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html583
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_policy_cd.pngbin25302 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_prime_size_policy.html149
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html173
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_gcc.pngbin6356 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_local.pngbin7405 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_msvc.pngbin6401 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html247
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html220
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html365
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram.pngbin12962 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram2.pngbin8918 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_ranged_hash_range_hashing_fns.pngbin19773 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_standard_resize_policy.html795
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html164
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html163
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_gcc.pngbin6910 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_local.pngbin8436 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_msvc.pngbin7204 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/index.html146
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_error.html53
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram1.pngbin25834 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram2.pngbin25522 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram3.pngbin24542 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/interface.html446
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/introduction.html120
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_cd.pngbin8331 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_erase.pngbin25884 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/join_error.html48
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/linear_probe_fn.html140
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update.html316
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu.pngbin20987 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu_based_containers.html229
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/misc.html26
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/motivation.html993
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/move_to_front_lu_policy.html194
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large.html215
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_gcc.pngbin6323 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_local.pngbin7299 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_msvc.pngbin6490 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_gcc.pngbin6284 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_local.pngbin6706 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_msvc.pngbin6204 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small.html215
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_gcc.pngbin6237 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_local.pngbin6732 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_msvc.pngbin6268 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_gcc.pngbin6064 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_local.pngbin6396 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_msvc.pngbin6012 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html210
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.pngbin6835 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_local.pngbin7275 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.pngbin6588 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.pngbin6778 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_local.pngbin7191 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.pngbin6535 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html212
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_gcc.pngbin6449 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_local.pngbin6845 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_msvc.pngbin6570 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_gcc.pngbin6419 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_local.pngbin6925 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_msvc.pngbin6569 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large.html212
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_gcc.pngbin6380 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_local.pngbin7000 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_msvc.pngbin6460 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_gcc.pngbin6204 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_local.pngbin6764 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_msvc.pngbin6357 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small.html217
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_gcc.pngbin6456 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_local.pngbin7035 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_msvc.pngbin6547 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_gcc.pngbin6111 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_local.pngbin6853 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_msvc.pngbin6430 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariant_invalidations.pngbin32276 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariants.pngbin16553 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_hash_fn.html32
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_lu_metadata.html25
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_mapped_type.html25
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_probe_fn.html29
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_tree_node_update.html101
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_trie_node_update.html102
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ov_tree_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_heap_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_gcc.pngbin5395 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_local.pngbin6892 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_msvc.pngbin5514 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_gcc.pngbin5678 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_local.pngbin6760 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_msvc.pngbin5878 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie.pngbin26182 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_invalidation_guarantee.html51
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_cd.pngbin20307 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_1.pngbin14206 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_2.pngbin12876 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_container_traits.html132
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_design.html381
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_different_underlying_dss.pngbin15660 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_examples.html54
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_performance_tests.html332
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_regression_tests.html52
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_tests.html24
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/prerequisites.html46
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue.html995
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test.html161
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_gcc.pngbin7350 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_local.pngbin9275 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_msvc.pngbin7065 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test.html200
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_gcc.pngbin7021 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_local.pngbin8986 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_msvc.pngbin7100 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.pngbin10845 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.svg368
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test.html141
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_gcc.pngbin6458 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_local.pngbin7989 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_msvc.pngbin6461 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html204
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_gcc.pngbin6788 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_local.pngbin7633 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_msvc.pngbin6956 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_gcc.pngbin5007 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_local.pngbin5878 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_msvc.pngbin4996 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test.html222
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_gcc.pngbin6950 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_local.pngbin7748 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_msvc.pngbin6983 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_gcc.pngbin4867 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_local.pngbin6105 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_msvc.pngbin5216 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test.html143
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_gcc.pngbin6582 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_local.pngbin7424 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_msvc.pngbin6849 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test.html209
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_gcc.pngbin7072 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_local.pngbin9006 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_msvc.pngbin7289 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test.html219
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_gcc.pngbin6832 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_local.pngbin8477 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_msvc.pngbin7266 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/quadratic_probe_fn.html141
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_gcc.pngbin5960 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_local.pngbin7377 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_msvc.pngbin5636 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/range_invalidation_guarantee.html52
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rationale_null_node_updator.pngbin25097 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rb_tree_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rc_binomial_heap_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/references.html258
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_error.html50
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_policy_cd.pngbin20806 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/restoring_node_invariants.pngbin14432 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_probe_fn.html152
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_range_hashing.html172
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_hash_fn.html171
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_probe_fn.html178
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_policy.html413
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_trigger.html462
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_size_policy.html163
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_tree_node_update.html193
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_e_access_traits.html231
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_node_update.html194
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_update_policy.html178
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/simple_list.pngbin4299 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/splay_tree_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/string_trie_e_access_traits.html400
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tests.html24
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_gcc.pngbin7013 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_local.pngbin9361 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_msvc.pngbin6932 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_gcc.pngbin6207 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_local.pngbin7650 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_msvc.pngbin6059 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/thin_heap_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree.html516
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_based_containers.html358
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_iterator.html143
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_updator_policy_cd.pngbin9236 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_node_update.html678
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test.html118
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_gcc.pngbin5698 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_local.pngbin6739 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_msvc.pngbin5684 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_random_int_find_find_timing_test.html160
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test.html143
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_gcc.pngbin5649 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_local.pngbin6734 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_msvc.pngbin5675 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_find_find_timing_test.html162
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test.html226
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_gcc.pngbin5373 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_local.pngbin6690 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_msvc.pngbin5212 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_gcc.pngbin4895 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_local.pngbin6011 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_msvc.pngbin4881 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_gcc.pngbin5140 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_local.pngbin6270 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_msvc.pngbin5131 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_find_timing_test.html126
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_gcc.pngbin6162 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_local.pngbin7796 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_msvc.pngbin5831 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie.html489
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_based_containers.html241
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_const_node_iterator.html478
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_iterator.html235
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_updator_policy_cd.pngbin12126 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_order_statistics_node_update.html770
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_prefix_search_node_update.html628
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_tag.html47
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trivial_iterator_tag.html25
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tutorial.html670
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_policy_cd.pngbin8570 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_seq_diagram.pngbin10789 -> 0 bytes
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/faq.html874
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/index.html43
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/abi.html521
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/algorithms.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/api.html154
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_contributing.html113
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_free.html124
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_gfdl.html395
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_gpl.html681
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_porting.html230
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/associative.html87
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/auto_ptr.html90
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/backwards.html932
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bitmap_allocator.html340
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bitset.html105
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01ix01.html48
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt02ch04s02.html49
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt02ch04s03.html29
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt02pr01.html17
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt03ch07s02.html20
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt03ch07s03.html4
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt03ch08.html45
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13.html95
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s02.html40
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s03.html57
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s04.html85
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s05.html15
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s06.html94
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt08ch19.html36
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt08ch19s02.html86
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt09ch20.html19
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt09pr02.html41
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt10ch23s02.html19
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch25s02.html77
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch27s02.html95
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch27s03.html22
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch28s02.html49
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch30s02.html55
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch30s03.html24
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch30s04.html409
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s02.html11
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s03.html66
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s04.html213
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s05.html26
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch33s02.html43
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch33s03.html50
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch40s02.html41
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch40s03.html37
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12pr03.html27
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/bugs.html330
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/codecvt.html379
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/complex.html25
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/configure.html201
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/containers.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/containers_and_c.html66
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/debug.html152
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/debug_mode.html37
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/diagnostics.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/documentation_style.html230
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/dynamic_memory.html69
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/exceptions.html22
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_algorithms.html23
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_allocators.html397
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_compile_checks.html40
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_concurrency.html91
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_containers.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_demangling.html74
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_io.html51
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_iterators.html14
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_numerics.html20
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_utilities.html41
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/extensions.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/facets.html77
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/fstreams.html52
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/functors.html15
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/fundamental_types.html43
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/generalized_numeric_operations.html29
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/internals.html374
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/intro.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/io.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/io_and_c.html11
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/iostream_objects.html119
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/iterators.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/license.html105
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/locales.html428
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/localization.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/make.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/memory.html349
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/messages.html284
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/numerics.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/numerics_and_c.html21
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/pairs.html42
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/parallel_mode.html24
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/sequences.html43
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/setup.html101
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/shared_ptr.html304
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/source_code_style.html588
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/source_design_notes.html863
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/source_organization.html97
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/spine.html57
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/status.html237
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/streambufs.html60
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/strings.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/stringstreams.html37
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/support.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/termination.html48
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/test.html489
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/traits.html10
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/using.html44
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/using_concurrency.html219
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/using_exceptions.html6
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/using_headers.html101
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/using_macros.html70
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/using_namespaces.html61
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/utilities.html9
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/vector.html16
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/manual/verbose_termination.html79
-rw-r--r--gcc-4.4.3/libstdc++-v3/doc/html/spine.html52
422 files changed, 0 insertions, 108608 deletions
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/README b/gcc-4.4.3/libstdc++-v3/doc/html/README
deleted file mode 100644
index ea5dcfcdd..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/README
+++ /dev/null
@@ -1,3 +0,0 @@
-The HTML documentation in this folder is generated from the XML sources.
-
-To change or edit, please edit the XML sources in the ../xml directory.
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/api.html b/gcc-4.4.3/libstdc++-v3/doc/html/api.html
deleted file mode 100644
index af2598365..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/api.html
+++ /dev/null
@@ -1,54 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>API and Source Level Documentation</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><link rel="home" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk02.html" title="" /><link rel="prev" href="bk02.html" title="" /><link rel="next" href="bk03.html" title="" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">API and Source Level Documentation</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk02.html">Prev</a> </td><th width="60%" align="center"></th><td width="20%" align="right"> <a accesskey="n" href="bk03.html">Next</a></td></tr></table><hr /></div><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="api"></a>API and Source Level Documentation</h2></div><div><p class="copyright">Copyright ©
- 2008
-
- <a class="ulink" href="http://www.fsf.org/" target="_top">FSF
- </a>
- </p></div><div><div class="legalnotice"><a id="id364806"></a><p>
- <a class="ulink" href="17_intro/license.html" target="_top">License
- </a>
- </p></div></div></div><hr /></div><p>
-The GNU C++ library sources have been specially formatted so that with the
-proper invocation of another tool (Doxygen), a set of HTML pages
-are generated from the sources files themselves. The resultant
-documentation is referred to as Source Level Documentation, and is
-useful for examining the signatures of public member functions for
-the library classes, finding out what is in a particular include
-file, looking at inheritance diagrams, etc.
-</p><p>
-The source-level documentation for the most recent releases can be
-viewed online:
-</p><div class="itemizedlist"><ul type="disc"><li><p>
- <a class="ulink" href="libstdc++-html-USERS-3.4/index.html" target="_top">for the 3.4 release
- </a>
- </p></li><li><p>
- <a class="ulink" href="libstdc++-html-USERS-4.1/index.html" target="_top">for the 4.1 release
- </a>
- </p></li><li><p>
- <a class="ulink" href="libstdc++-html-USERS-4.2/index.html" target="_top">for the 4.2 release
- </a>
- </p></li><li><p>
- <a class="ulink" href="libstdc++-html-USERS-4.3/index.html" target="_top">for the 4.3 release
- </a>
- </p></li><li><p>
- <a class="ulink" href="libstdc++-html-USERS-4.4/index.html" target="_top">for the 4.4 release
- </a>
- </p></li><li><p>
- <a class="ulink" href="latest-doxygen/index.html" target="_top">"the latest collection"
- </a>
- (For the main development tree; see the date on the first page.)
- </p></li></ul></div><p>
-This generated HTML collection, as above, is also available for download in the libstdc++ snapshots directory at
- <code class="literal">&lt;URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/doxygen/&gt;</code>.
- You will almost certainly need to use one of the
- <a class="ulink" href="http://gcc.gnu.org/mirrors.html" target="_top">mirror sites</a> to download
- the tarball. After unpacking, simply load libstdc++-html-*/index.html
- into a browser.
-</p><p>
-Documentation for older releases is available for download only, not
-online viewing.
-</p><p>
-In addition, an initial set of man pages are also available in the
-same place as the HTML collections. Start with C++Intro(3).
-</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk02.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="spine.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/bk02.html b/gcc-4.4.3/libstdc++-v3/doc/html/bk02.html
deleted file mode 100644
index e765d9eae..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/bk02.html
+++ /dev/null
@@ -1,3 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><link rel="home" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="prev" href="manual/backwards.html" title="Backwards Compatibility" /><link rel="next" href="api.html" title="API and Source Level Documentation" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="manual/backwards.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr></table><hr /></div><div class="book" lang="en" xml:lang="en"><div class="titlepage"><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="article"><a href="api.html">API and Source Level Documentation</a></span></dt></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="manual/backwards.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Backwards Compatibility </td><td width="20%" align="center"><a accesskey="h" href="spine.html">Home</a></td><td width="40%" align="right" valign="top"> API and Source Level Documentation</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/bk03.html b/gcc-4.4.3/libstdc++-v3/doc/html/bk03.html
deleted file mode 100644
index 1d08fc98e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/bk03.html
+++ /dev/null
@@ -1,3 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><link rel="home" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="prev" href="api.html" title="API and Source Level Documentation" /><link rel="next" href="faq.html" title="Frequently Asked Questions" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="api.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="faq.html">Next</a></td></tr></table><hr /></div><div class="book" lang="en" xml:lang="en"><div class="titlepage"><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="article"><a href="faq.html">Frequently Asked Questions</a></span></dt></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="api.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="faq.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">API and Source Level Documentation </td><td width="20%" align="center"><a accesskey="h" href="spine.html">Home</a></td><td width="40%" align="right" valign="top"> Frequently Asked Questions</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html
deleted file mode 100644
index 94b57c0a6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-active.html
+++ /dev/null
@@ -1,19718 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
-<html><head>
-<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
-
-
-<title>C++ Standard Library Active Issues List</title>
-<style type="text/css">
-p {text-align:justify}
-li {text-align:justify}
-ins {background-color:#A0FFA0}
-del {background-color:#FFA0A0}
-</style>
-</head><body>
-<table>
-<tbody><tr>
-<td align="left">Doc. no.</td>
-<td align="left">N2727=08-0237</td>
-</tr>
-<tr>
-<td align="left">Date:</td>
-<td align="left">2008-08-24</td>
-</tr>
-<tr>
-<td align="left">Project:</td>
-<td align="left">Programming Language C++</td>
-</tr>
-<tr>
-<td align="left">Reply to:</td>
-<td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
-</tr>
-</tbody></table>
-<h1>C++ Standard Library Active Issues List (Revision R59)</h1>
-
- <p>Reference ISO/IEC IS 14882:1998(E)</p>
- <p>Also see:</p>
- <ul>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
- </ul>
- <p>The purpose of this document is to record the status of issues
- which have come before the Library Working Group (LWG) of the ANSI
- (J16) and ISO (WG21) C++ Standards Committee. Issues represent
- potential defects in the ISO/IEC IS 14882:1998(E) document. Issues
- are not to be used to request new features. </p>
-
- <p>This document contains only library issues which are actively being
- considered by the Library Working Group. That is, issues which have a
- status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>,
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>. See
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered defects and
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues considered closed.</p>
-
- <p>The issues in these lists are not necessarily formal ISO Defect
- Reports (DR's). While some issues will eventually be elevated to
- official Defect Report status, other issues will be disposed of in
- other ways. See <a href="#Status">Issue Status</a>.</p>
-
- <p>This document is in an experimental format designed for both
- viewing via a world-wide web browser and hard-copy printing. It
- is available as an HTML file for browsing or PDF file for
- printing.</p>
-
- <p>Prior to Revision 14, library issues lists existed in two slightly
- different versions; a Committee Version and a Public
- Version. Beginning with Revision 14 the two versions were combined
- into a single version.</p>
-
- <p>This document includes <i>[bracketed italicized notes]</i> as a
- reminder to the LWG of current progress on issues. Such notes are
- strictly unofficial and should be read with caution as they may be
- incomplete or incorrect. Be aware that LWG support for a particular
- resolution can quickly change if new viewpoints or killer examples are
- presented in subsequent discussions.</p>
-
- <p>For the most current official version of this document see
- <a href="http://www.open-std.org/jtc1/sc22/wg21/">http://www.open-std.org/jtc1/sc22/wg21/</a>.
- Requests for further information about this document should include
- the document number above, reference ISO/IEC 14882:1998(E), and be
- submitted to Information Technology Industry Council (ITI), 1250 Eye
- Street NW, Washington, DC 20005.</p>
-
- <p>Public information as to how to obtain a copy of the C++ Standard,
- join the standards committee, submit an issue, or comment on an issue
- can be found in the comp.std.c++ FAQ.
- Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c++">news:comp.std.c++</a>.
- </p>
-
- <p>For committee members, files available on the committee's private
- web site include the HTML version of the Standard itself. HTML
- hyperlinks from this issues list to those files will only work for
- committee members who have downloaded them into the same disk
- directory as the issues list files. </p>
-
-<h2>Revision History</h2>
-<ul>
-<li>R59:
-2008-08-22 pre-San Francisco mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>192 open issues, up by 9.</li>
-<li>686 closed issues, up by 0.</li>
-<li>878 issues total, up by 9.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R58:
-2008-07-28 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>183 open issues, up by 12.</li>
-<li>686 closed issues, down by 4.</li>
-<li>869 issues total, up by 8.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
-<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
-<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R57:
-2008-06-27 post-Sophia Antipolis mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>171 open issues, down by 20.</li>
-<li>690 closed issues, up by 43.</li>
-<li>861 issues total, up by 23.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li>
-<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li>
-<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li>
-<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
-<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
-<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li>
-<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
-<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R56:
-2008-05-16 pre-Sophia Antipolis mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>191 open issues, up by 24.</li>
-<li>647 closed issues, up by 1.</li>
-<li>838 issues total, up by 25.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R55:
-2008-03-14 post-Bellevue mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>167 open issues, down by 39.</li>
-<li>646 closed issues, up by 65.</li>
-<li>813 issues total, up by 26.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
-<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
-<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li>
-<li>Changed the following issues from NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li>
-<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>.</li>
-<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
-<li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li>
-<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
-<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
-<li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
-<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
-<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R54:
-2008-02-01 pre-Bellevue mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>206 open issues, up by 23.</li>
-<li>581 closed issues, up by 0.</li>
-<li>787 issues total, up by 23.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
-<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li>
-<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>.</li>
-<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li>
-<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>.</li>
-<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R53:
-2007-12-09 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>183 open issues, up by 11.</li>
-<li>581 closed issues, down by 1.</li>
-<li>764 issues total, up by 10.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
-<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li>
-<li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R52:
-2007-10-19 post-Kona mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>172 open issues, up by 4.</li>
-<li>582 closed issues, up by 27.</li>
-<li>754 issues total, up by 31.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
-<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li>
-<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
-<li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li>
-<li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li>
-<li>Changed the following issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R51:
-2007-09-09 pre-Kona mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>168 open issues, up by 15.</li>
-<li>555 closed issues, up by 0.</li>
-<li>723 issues total, up by 15.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R50:
-2007-08-05 post-Toronto mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>153 open issues, down by 5.</li>
-<li>555 closed issues, up by 17.</li>
-<li>708 issues total, up by 12.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>.</li>
-<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.</li>
-<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
-<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
-<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>.</li>
-<li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
-<li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R49:
-2007-06-23 pre-Toronto mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>158 open issues, up by 13.</li>
-<li>538 closed issues, up by 7.</li>
-<li>696 issues total, up by 20.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
-<li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>.</li>
-<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R48:
-2007-05-06 post-Oxford mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>145 open issues, down by 33.</li>
-<li>531 closed issues, up by 53.</li>
-<li>676 issues total, up by 20.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li>
-<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
-<li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li>
-<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li>
-<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
-<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
-<li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li>
-<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R47:
-2007-03-09 pre-Oxford mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>178 open issues, up by 37.</li>
-<li>478 closed issues, up by 0.</li>
-<li>656 issues total, up by 37.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
-<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
-<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R46:
-2007-01-12 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>141 open issues, up by 11.</li>
-<li>478 closed issues, down by 1.</li>
-<li>619 issues total, up by 10.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R45:
-2006-11-03 post-Portland mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>130 open issues, up by 0.</li>
-<li>479 closed issues, up by 17.</li>
-<li>609 issues total, up by 17.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a> to WP.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a> to NAD.</li>
-<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a> to Review.</li>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R44:
-2006-09-08 pre-Portland mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>130 open issues, up by 6.</li>
-<li>462 closed issues, down by 1.</li>
-<li>592 issues total, up by 5.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R43:
-2006-06-23 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>124 open issues, up by 14.</li>
-<li>463 closed issues, down by 1.</li>
-<li>587 issues total, up by 13.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li>
-<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.</li>
-</ul></li>
-</ul>
-</li>
-<li>R42:
-2006-04-21 post-Berlin mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>110 open issues, down by 16.</li>
-<li>464 closed issues, up by 24.</li>
-<li>574 issues total, up by 8.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
-<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
-<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
-</ul></li>
-</ul>
-</li>
-<li>R41:
-2006-02-24 pre-Berlin mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>126 open issues, up by 31.</li>
-<li>440 closed issues, up by 0.</li>
-<li>566 issues total, up by 31.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
-<li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
-<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R40:
-2005-12-16 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>95 open issues.</li>
-<li>440 closed issues.</li>
-<li>535 issues total.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R39:
-2005-10-14 post-Mont Tremblant mailing.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready.
-Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
-Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
-</li>
-<li>R38:
-2005-07-03 pre-Mont Tremblant mailing.
-Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
-</li>
-<li>R37:
-2005-06 mid-term mailing.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>.
-</li>
-<li>R36:
-2005-04 post-Lillehammer mailing. All issues in "ready" status except
-for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues
-previously in "DR" status were moved to "WP".
-</li>
-<li>R35:
-2005-03 pre-Lillehammer mailing.
-</li>
-<li>R34:
-2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
-</li>
-<li>R33:
-2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
-</li>
-<li>R32:
-2004-09 pre-Redmond mailing: reflects new proposed resolutions and
-new issues received after the 2004-07 mailing. Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
-</li>
-<li>R31:
-2004-07 mid-term mailing: reflects new proposed resolutions and
-new issues received after the post-Sydney mailing. Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
-</li>
-<li>R30:
-Post-Sydney mailing: reflects decisions made at the Sydney meeting.
-Voted all "Ready" issues from R29 into the working paper.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>.
-</li>
-<li>R29:
-Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
-</li>
-<li>R28:
-Post-Kona mailing: reflects decisions made at the Kona meeting.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>.
-</li>
-<li>R27:
-Pre-Kona mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
-</li>
-<li>R26:
-Post-Oxford mailing: reflects decisions made at the Oxford meeting.
-All issues in Ready status were voted into DR status. All issues in
-DR status were voted into WP status.
-</li>
-<li>R25:
-Pre-Oxford mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>.
-</li>
-<li>R24:
-Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
-meeting. All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
-moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
-at the meeting.) Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
-concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
-</li>
-<li>R23:
-Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#382">382</a>.
-Moved issues in the TC to TC status.
-</li>
-<li>R22:
-Post-Curaao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
-</li>
-<li>R21:
-Pre-Curaao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>.
-</li>
-<li>R20:
-Post-Redmond mailing; reflects actions taken in Redmond. Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a> were added since Redmond, hence
-not discussed at the meeting.
-
-All Ready issues were moved to DR status, with the exception of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
-
-Noteworthy issues discussed at Redmond include
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
-</li>
-<li>R19:
-Pre-Redmond mailing. Added new issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>.
-</li>
-<li>R18:
-Post-Copenhagen mailing; reflects actions taken in Copenhagen.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>.
-
-Changed status of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
-to DR.
-
-Changed status of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>
-to Ready.
-
-Closed issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
-as NAD.
-
-</li>
-<li>R17:
-Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
-resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>.
-</li>
-<li>R16:
-post-Toronto mailing; reflects actions taken in Toronto. Added new
-issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>. Changed status of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>. Reopened
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
-appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
-the bug in enough places.
-</li>
-<li>R15:
-pre-Toronto mailing. Added issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>. Some small HTML formatting
-changes so that we pass Weblint tests.
-</li>
-<li>R14:
-post-Tokyo II mailing; reflects committee actions taken in
-Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
-</li>
-<li>R13:
-pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.
-</li>
-<li>R12:
-pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
-of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
-</li>
-<li>R11:
-post-Kona mailing: Updated to reflect LWG and full committee actions
-in Kona (99-0048/N1224). Note changed resolution of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a>
-to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
-"closed" documents. Changed the proposed resolution of issue
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
-of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
-</li>
-<li>R10:
-pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a> to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
-</li>
-<li>R9:
-pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
-"closed" documents. (99-0030/N1206, 25 Aug 99)
-</li>
-<li>R8:
-post-Dublin mailing. Updated to reflect LWG and full committee actions
-in Dublin. (99-0016/N1193, 21 Apr 99)
-</li>
-<li>R7:
-pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
-</li>
-<li>R6:
-pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>,
-and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
-</li>
-<li>R5:
-update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>. Format revisions to prepare
-for making list public. (30 Dec 98)
-</li>
-<li>R4:
-post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
-issues corrected. (22 Oct 98)
-</li>
-<li>R3:
-post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>
-added, many issues updated to reflect LWG consensus (12 Oct 98)
-</li>
-<li>R2:
-pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added,
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
-</li>
-<li>R1:
-Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code
-format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
-</li>
-</ul>
-
-<h2><a name="Status"></a>Issue Status</h2>
-
- <p><b><a name="New">New</a></b> - The issue has not yet been
- reviewed by the LWG. Any <b>Proposed Resolution</b> is purely a
- suggestion from the issue submitter, and should not be construed as
- the view of LWG.</p>
-
- <p><b><a name="Open">Open</a></b> - The LWG has discussed the issue
- but is not yet ready to move the issue forward. There are several
- possible reasons for open status:</p>
- <ul>
- <li>Consensus may have not yet have been reached as to how to deal
- with the issue.</li>
- <li>Informal consensus may have been reached, but the LWG awaits
- exact <b>Proposed Resolution</b> wording for review.</li>
- <li>The LWG wishes to consult additional technical experts before
- proceeding.</li>
- <li>The issue may require further study.</li>
- </ul>
-
- <p>A <b>Proposed Resolution</b> for an open issue is still not be
- construed as the view of LWG. Comments on the current state of
- discussions are often given at the end of open issues in an italic
- font. Such comments are for information only and should not be given
- undue importance.</p>
-
- <p><b><a name="Dup">Dup</a></b> - The LWG has reached consensus that
- the issue is a duplicate of another issue, and will not be further
- dealt with. A <b>Rationale</b> identifies the duplicated issue's
- issue number. </p>
-
- <p><b><a name="NAD">NAD</a></b> - The LWG has reached consensus that
- the issue is not a defect in the Standard.</p>
-
- <p><b><a name="NAD Editorial">NAD Editorial</a></b> - The LWG has reached consensus that
- the issue can either be handled editorially, or is handled by a paper (usually
- linked to in the rationale).</p>
-
- <p><b><a name="NAD Future">NAD Future</a></b> - In addition to the regular
- status, the LWG believes that this issue should be revisited at the
- next revision of the standard.</p>
-
- <p><b><a name="Review">Review</a></b> - Exact wording of a
- <b>Proposed Resolution</b> is now available for review on an issue
- for which the LWG previously reached informal consensus.</p>
-
- <p><b><a name="Tentatively Ready">Tentatively Ready</a></b> - The issue has
- been reviewed online, but not in a meeting, and some support has been formed
- for the proposed resolution. Tentatively Ready issues may be moved to Ready
- and forwarded to full committee within the same meeting. Unlike Ready issues
- they will be reviewed in subcommittee prior to forwarding to full committee.</p>
-
- <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus
- that the issue is a defect in the Standard, the <b>Proposed
- Resolution</b> is correct, and the issue is ready to forward to the
- full committee for further action as a Defect Report (DR).</p>
-
- <p><b><a name="DR">DR</a></b> - (Defect Report) - The full J16
- committee has voted to forward the issue to the Project Editor to be
- processed as a Potential Defect Report. The Project Editor reviews
- the issue, and then forwards it to the WG21 Convenor, who returns it
- to the full committee for final disposition. This issues list
- accords the status of DR to all these Defect Reports regardless of
- where they are in that process.</p>
-
- <p><b><a name="TC">TC</a></b> - (Technical Corrigenda) - The full
- WG21 committee has voted to accept the Defect Report's Proposed
- Resolution as a Technical Corrigenda. Action on this issue is thus
- complete and no further action is possible under ISO rules.</p>
-
- <p><b><a name="TRDec">TRDec</a></b> - (Decimal TR defect) - The
- LWG has voted to accept the Defect Report's Proposed
- Resolution into the Decimal TR. Action on this issue is thus
- complete and no further action is expected.</p>
-
- <p><b><a name="WP">WP</a></b> - (Working Paper) - The proposed
- resolution has not been accepted as a Technical Corrigendum, but
- the full WG21 committee has voted to apply the Defect Report's Proposed
- Resolution to the working paper.</p>
-
- <p><b>Pending</b> - This is a <i>status qualifier</i>. When prepended to
- a status this indicates the issue has been
- processed by the committee, and a decision has been made to move the issue to
- the associated unqualified status. However for logistical reasons the indicated
- outcome of the issue has not yet appeared in the latest working paper.
-
- </p><p>Issues are always given the status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> when
- they first appear on the issues list. They may progress to
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> while the LWG
- is actively working on them. When the LWG has reached consensus on
- the disposition of an issue, the status will then change to
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>, or
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> as appropriate. Once the full J16 committee votes to
- forward Ready issues to the Project Editor, they are given the
- status of Defect Report ( <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>). These in turn may
- become the basis for Technical Corrigenda (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>),
- or are closed without action other than a Record of Response
- (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a> ). The intent of this LWG process is that
- only issues which are truly defects in the Standard move to the
- formal ISO DR status.
- </p>
-
-
-<h2>Active Issues</h2>
-<hr>
-<h3><a name="23"></a>23. Num_get overflow result</h3>
-<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The current description of numeric input does not account for the
-possibility of overflow. This is an implicit result of changing the
-description to rely on the definition of scanf() (which fails to
-report overflow), and conflicts with the documented behavior of
-traditional and current implementations. </p>
-
-<p>Users expect, when reading a character sequence that results in a
-value unrepresentable in the specified type, to have an error
-reported. The standard as written does not permit this. </p>
-
-<p><b>Further comments from Dietmar:</b></p>
-
-<p>
-I don't feel comfortable with the proposed resolution to issue 23: It
-kind of simplifies the issue to much. Here is what is going on:
-</p>
-
-<p>
-Currently, the behavior of numeric overflow is rather counter intuitive
-and hard to trace, so I will describe it briefly:
-</p>
-
-<ul>
- <li>
- According to 22.2.2.1.2 [facet.num.get.virtuals]
- paragraph 11 <tt>failbit</tt> is set if <tt>scanf()</tt> would
- return an input error; otherwise a value is converted to the rules
- of <tt>scanf</tt>.
- </li>
- <li>
- <tt>scanf()</tt> is defined in terms of <tt>fscanf()</tt>.
- </li>
- <li>
- <tt>fscanf()</tt> returns an input failure if during conversion no
- character matching the conversion specification could be extracted
- before reaching EOF. This is the only reason for <tt>fscanf()</tt>
- to fail due to an input error and clearly does not apply to the case
- of overflow.
- </li>
- <li>
- Thus, the conversion is performed according to the rules of
- <tt>fscanf()</tt> which basically says that <tt>strtod</tt>,
- <tt>strtol()</tt>, etc. are to be used for the conversion.
- </li>
- <li>
- The <tt>strtod()</tt>, <tt>strtol()</tt>, etc. functions consume as
- many matching characters as there are and on overflow continue to
- consume matching characters but also return a value identical to
- the maximum (or minimum for signed types if there was a leading minus)
- value of the corresponding type and set <tt>errno</tt> to <tt>ERANGE</tt>.
- </li>
- <li>
- Thus, according to the current wording in the standard, overflows
- can be detected! All what is to be done is to check <tt>errno</tt>
- after reading an element and, of course, clearing <tt>errno</tt>
- before trying a conversion. With the current wording, it can be
- detected whether the overflow was due to a positive or negative
- number for signed types.
- </li>
-</ul>
-
-<p><b>Further discussion from Redmond:</b></p>
-
-<p>The basic problem is that we've defined our behavior,
-including our error-reporting behavior, in terms of C90. However,
-C90's method of reporting overflow in scanf is not technically an
-"input error". The <tt>strto_*</tt> functions are more precise.</p>
-
-<p>There was general consensus that <tt>failbit</tt> should be set
-upon overflow. We considered three options based on this:</p>
-<ol>
-<li>Set failbit upon conversion error (including overflow), and
- don't store any value.</li>
-<li>Set failbit upon conversion error, and also set <tt>errno</tt> to
- indicated the precise nature of the error.</li>
-<li>Set failbit upon conversion error. If the error was due to
- overflow, store +-numeric_limits&lt;T&gt;::max() as an
- overflow indication.</li>
-</ol>
-
-<p>Straw poll: (1) 5; (2) 0; (3) 8.</p>
-
-
-<p>Discussed at Lillehammer. General outline of what we want the
- solution to look like: we want to say that overflow is an error, and
- provide a way to distinguish overflow from other kinds of errors.
- Choose candidate field the same way scanf does, but don't describe
- the rest of the process in terms of format. If a finite input field
- is too large (positive or negative) to be represented as a finite
- value, then set failbit and assign the nearest representable value.
- Bill will provide wording.</p>
-
-<p>
-Discussed at Toronto:
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
-is in alignment with the direction we wanted to go with in Lillehammer. Bill
-to work on.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 22.2.2.1.2 [facet.num.get.virtuals], end of p3:
-</p>
-
-<blockquote>
-<p>
-<b>Stage 3:</b> <del>The result of stage 2 processing can be one of</del>
-<ins>The sequence of <tt>char</tt>s accumulated in stage 2 (the field) is
-converted to a numeric value by the rules of one of the functions declared
-in the header <tt>&lt;cstdlib&gt;</tt>:</ins>
-</p>
-<ul>
-<li>
-<del>A sequence of <tt>char</tt>s has been accumulated in stage 2 that is
-converted (according to the rules of <tt>scanf</tt>) to a value of the
-type of <i>val</i>. This value is stored in <i>val</i> and <tt>ios_base::goodbit</tt> is
-stored in <i>err</i>.</del>
-<ins>For a signed integer value, the function <tt>strtoll</tt>.</ins>
-</li>
-<li>
-<del>The sequence of <tt>char</tt>s accumulated in stage 2 would have caused
-<tt>scanf</tt> to report an input failure. <tt>ios_base::failbit</tt> is
-assigned to <i>err</i>.</del>
-<ins>For an unsigned integer value, the function <tt>strtoull</tt>.</ins>
-</li>
-<li>
-<ins>For a floating-point value, the function <tt>strtold</tt>.</ins>
-</li>
-</ul>
-<p>
-<ins>The numeric value to be stored can be one of:</ins>
-</p>
-<ul>
-<li><ins>zero, if the conversion function fails to convert the entire field.
-<tt>ios_base::failbit</tt> is assigned to err.</ins></li>
-<li><ins>the most positive representable value, if the field represents a value
-too large positive to be represented in <i>val</i>. <tt>ios_base::failbit</tt> is assigned
-to <i>err</i>.</ins></li>
-<li><ins>the most negative representable value (zero for unsigned integer), if
-the field represents a value too large negative to be represented in <i>val</i>.
-<tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins></li>
-<li><ins>the converted value, otherwise.</ins></li>
-</ul>
-
-<p><ins>
-The resultant numeric value is stored in <i>val</i>.
-</ins></p>
-</blockquote>
-
-<p>
-Change 22.2.2.1.2 [facet.num.get.virtuals], p6-p7:
-</p>
-
-<blockquote>
-<pre>iter_type do_get(iter_type <i>in</i>, iter_type <i>end</i>, ios_base&amp; <i>str</i>,
- ios_base::iostate&amp; <i>err</i>, bool&amp; <i>val</i>) const;
-</pre>
-<blockquote>
-<p>
--6- <i>Effects:</i> If
-<tt>(<i>str</i>.flags()&amp;ios_base::boolalpha)==0</tt> then input
-proceeds as it would for a <tt>long</tt> except that if a value is being
-stored into <i>val</i>, the value is determined according to the
-following: If the value to be stored is 0 then <tt>false</tt> is stored.
-If the value is 1 then <tt>true</tt> is stored. Otherwise
-<del><tt><i>err</i>|=ios_base::failbit</tt> is performed and no value</del> <ins><tt>true</tt></ins> is
-stored<del>.</del> <ins>and <tt>ios_base::failbit</tt> is assigned to <i>err</i>.</ins>
-</p>
-<p>
--7- Otherwise target sequences are determined "as if" by calling the
-members <tt>falsename()</tt> and <tt>truename()</tt> of the facet
-obtained by <tt>use_facet&lt;numpunct&lt;charT&gt;
-&gt;(<i>str</i>.getloc())</tt>. Successive characters in the range
-<tt>[<i>in</i>,<i>end</i>)</tt> (see 23.1.1) are obtained and matched
-against corresponding positions in the target sequences only as
-necessary to identify a unique match. The input iterator <i>in</i> is
-compared to <i>end</i> only when necessary to obtain a character. If <del>and
-only if</del> a target sequence is uniquely matched, <i>val</i> is set to the
-corresponding value. <ins>Otherwise <tt>false</tt> is stored and <tt>ios_base::failbit</tt>
-is assigned to <i>err</i>.</ins>
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="96"></a>96. Vector&lt;bool&gt; is not a container</h3>
-<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p><tt>vector&lt;bool&gt;</tt> is not a container as its reference and
-pointer types are not references and pointers. </p>
-
-<p>Also it forces everyone to have a space optimization instead of a
-speed one.</p>
-
-<p><b>See also:</b> 99-0008 == N1185 Vector&lt;bool&gt; is
-Nonconforming, Forces Optimization Choice.</p>
-
-<p><i>[In Santa Cruz the LWG felt that this was Not A Defect.]</i></p>
-
-
-<p><i>[In Dublin many present felt that failure to meet Container
-requirements was a defect. There was disagreement as to whether
-or not the optimization requirements constituted a defect.]</i></p>
-
-
-<p><i>[The LWG looked at the following resolutions in some detail:
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Not A Defect.<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Add a note explaining that vector&lt;bool&gt; does not meet
-Container requirements.<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Remove vector&lt;bool&gt;.<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Add a new category of container requirements which
-vector&lt;bool&gt; would meet.<br>
-&nbsp;&nbsp;&nbsp;&nbsp; * Rename vector&lt;bool&gt;.<br>
-<br>
-No alternative had strong, wide-spread, support and every alternative
-had at least one "over my dead body" response.<br>
-<br>
-There was also mention of a transition scheme something like (1) add
-vector_bool and deprecate vector&lt;bool&gt; in the next standard. (2)
-Remove vector&lt;bool&gt; in the following standard.]</i></p>
-
-
-<p><i>[Modifying container requirements to permit returning proxies
-(thus allowing container requirements conforming vector&lt;bool&gt;)
-was also discussed.]</i></p>
-
-
-<p><i>[It was also noted that there is a partial but ugly workaround in
-that vector&lt;bool&gt; may be further specialized with a customer
-allocator.]</i></p>
-
-
-<p><i>[Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211,
-vector&lt;bool&gt;: More Problems, Better Solutions. Much discussion
-of a two step approach: a) deprecate, b) provide replacement under a
-new name. LWG straw vote on that: 1-favor, 11-could live with, 2-over
-my dead body. This resolution was mentioned in the LWG report to the
-full committee, where several additional committee members indicated
-over-my-dead-body positions.]</i></p>
-
-
-<p>Discussed at Lillehammer. General agreement that we should
- deprecate vector&lt;bool&gt; and introduce this functionality under
- a different name, e.g. bit_vector. This might make it possible to
- remove the vector&lt;bool&gt; specialization in the standard that comes
- after C++0x. There was also a suggestion that
- in C++0x we could additional say that it's implementation defined
- whether vector&lt;bool&gt; refers to the specialization or to the
- primary template, but there wasn't general agreement that this was a
- good idea.</p>
-
-<p>We need a paper for the new bit_vector class.</p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-We now have:
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
-and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2160.html">N2160</a>.
-</p>
-
-<p><i>[
-Batavia: The LWG feels we need something closer to SGI's <tt>bitvector</tt> to ease migration
-from <tt>vector&lt;bool&gt;</tt>. Although some of the funcitonality from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2050.pdf">N2050</a>
-could well be used in such a template. The concern is easing the API migration for those
-users who want to continue using a bit-packed container. Alan and Beman to work.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="128"></a>128. Need open_mode() function for file stream, string streams, file buffers, and string&nbsp; buffers</h3>
-<p><b>Section:</b> 27.7 [string.streams], 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The following question came from Thorsten Herlemann:</p>
-
-<blockquote>
- <p>You can set a mode when constructing or opening a file-stream or
- filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get
- that mode later on, e.g. in my own operator &lt;&lt; or operator
- &gt;&gt; or when I want to check whether a file-stream or
- file-buffer object passed as parameter is opened for input or output
- or binary? Is there no possibility? Is this a design-error in the
- standard C++ library? </p>
-</blockquote>
-
-<p>It is indeed impossible to find out what a stream's or stream
-buffer's open mode is, and without that knowledge you don't know
-how certain operations behave. Just think of the append mode. </p>
-
-<p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
-current open mode setting. </p>
-
-<p><i>[
-post Bellevue: Alisdair requested to re-Open.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>For stream buffers, add a function to the base class as a non-virtual function
-qualified as const to 27.5.2 [streambuf]:</p>
-
-<p>&nbsp;&nbsp;&nbsp;&nbsp;<tt>openmode mode() const</tt>;</p>
-
-<p><b>&nbsp;&nbsp;&nbsp; Returns</b> the current open mode.</p>
-
-<p>With streams, I'm not sure what to suggest. In principle, the mode
-could already be returned by <tt>ios_base</tt>, but the mode is only
-initialized for file and string stream objects, unless I'm overlooking
-anything. For this reason it should be added to the most derived
-stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
-and would be default initialized in <tt>basic_ios&lt;&gt;::init()</tt>.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This might be an interesting extension for some future, but it is
-not a defect in the current standard. The Proposed Resolution is
-retained for future reference.</p>
-
-
-
-
-
-<hr>
-<h3><a name="180"></a>180. Container member iterator arguments constness has unintended consequences</h3>
-<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1999-07-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>It is the constness of the container which should control whether
-it can be modified through a member function such as erase(), not the
-constness of the iterators. The iterators only serve to give
-positioning information.</p>
-
-<p>Here's a simple and typical example problem which is currently very
-difficult or impossible to solve without the change proposed
-below.</p>
-
-<p>Wrap a standard container C in a class W which allows clients to
-find and read (but not modify) a subrange of (C.begin(), C.end()]. The
-only modification clients are allowed to make to elements in this
-subrange is to erase them from C through the use of a member function
-of W.</p>
-
-<p><i>[
-post Bellevue, Alisdair adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-This issue was implemented by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>
-for everything but <tt>basic_string</tt>.
-</p>
-
-<p>
-Note that the specific example in this issue (<tt>basic_string</tt>) is the one place
-we forgot to amend in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf">N2350</a>,
-so we might open this issue for that
-single container?
-</p>
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-This was a fix that was intended for all standard library containers,
-and has been done for other containers, but string was missed.
-</p>
-<p>
-The wording updated.
-</p>
-<p>
-We did not make the change in <tt>replace</tt>, because this change would affect
-the implementation because the string may be written into. This is an
-issue that should be taken up by concepts.
-</p>
-<p>
-We note that the supplied wording addresses the initializer list provided in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2679.pdf">N2679</a>.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Update the following signature in the <tt>basic_string</tt> class template definition in
-21.3 [basic.string], p5:
-</p>
-<blockquote><pre>namespace std {
- template&lt;class charT, class traits = char_traits&lt;charT&gt;,
- class Allocator = allocator&lt;charT&gt; &gt;
- class basic_string {
-
- ...
-
- iterator insert(<ins>const_</ins>iterator p, charT c);
- void insert(<ins>const_</ins>iterator p, size_type n, charT c);
- template&lt;class InputIterator&gt;
- void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
- void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
-
- ...
-
- iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
- iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
-
- ...
-
- };
-}
-</pre></blockquote>
-
-<p>
-Update the following signatures in 21.3.6.4 [string::insert]:
-</p>
-
-<blockquote><pre>iterator insert(<ins>const_</ins>iterator p, charT c);
-void insert(<ins>const_</ins>iterator p, size_type n, charT c);
-template&lt;class InputIterator&gt;
- void insert(<ins>const_</ins>iterator p, InputIterator first, InputIterator last);
-void insert(<ins>const_</ins>iterator <ins>p</ins>, initializer_list&lt;charT&gt;);
-</pre></blockquote>
-
-<p>
-Update the following signatures in 21.3.6.5 [string::erase]:
-</p>
-
-<blockquote><pre>iterator erase(<ins>const_</ins>iterator <ins>const_</ins>position);
-iterator erase(<ins>const_</ins>iterator first, <ins>const_</ins>iterator last);
-</pre></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>The issue was discussed at length. It was generally agreed that 1)
-There is no major technical argument against the change (although
-there is a minor argument that some obscure programs may break), and
-2) Such a change would not break const correctness. The concerns about
-making the change were 1) it is user detectable (although only in
-boundary cases), 2) it changes a large number of signatures, and 3) it
-seems more of a design issue that an out-and-out defect.</p>
-
-<p>The LWG believes that this issue should be considered as part of a
-general review of const issues for the next revision of the
-standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>
-
-
-
-
-<hr>
-<h3><a name="190"></a>190. min() and max() functions should be std::binary_functions</h3>
-<p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Mark Rintoul <b>Date:</b> 1999-08-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Both std::min and std::max are defined as template functions. This
-is very different than the definition of std::plus (and similar
-structs) which are defined as function objects which inherit
-std::binary_function.<br>
-<br>
- This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
-a function object that inherits std::binary_function.</p>
-
-<p><i>[
-post Bellevue: Alisdair requested to re-Open.
-]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>Although perhaps an unfortunate design decision, the omission is not a defect
-in the current standard.&nbsp; A future standard may wish to consider additional
-function objects.</p>
-
-
-
-
-<hr>
-<h3><a name="255"></a>255. Why do <tt>basic_streambuf&lt;&gt;::pbump()</tt> and <tt>gbump()</tt> take an int?</h3>
-<p><b>Section:</b> 27.5.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The basic_streambuf members gbump() and pbump() are specified to take an
-int argument. This requirement prevents the functions from effectively
-manipulating buffers larger than std::numeric_limits&lt;int&gt;::max()
-characters. It also makes the common use case for these functions
-somewhat difficult as many compilers will issue a warning when an
-argument of type larger than int (such as ptrdiff_t on LLP64
-architectures) is passed to either of the function. Since it's often the
-result of the subtraction of two pointers that is passed to the
-functions, a cast is necessary to silence such warnings. Finally, the
-usage of a native type in the functions signatures is inconsistent with
-other member functions (such as sgetn() and sputn()) that manipulate the
-underlying character buffer. Those functions take a streamsize argument.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the signatures of these functions in the synopsis of template
-class basic_streambuf (27.5.2) and in their descriptions (27.5.2.3.1, p4
-and 27.5.2.3.2, p4) to take a streamsize argument.
-</p>
-
-<p>
-Although this change has the potential of changing the ABI of the
-library, the change will affect only platforms where int is different
-than the definition of streamsize. However, since both functions are
-typically inline (they are on all known implementations), even on such
-platforms the change will not affect any user code unless it explicitly
-relies on the existing type of the functions (e.g., by taking their
-address). Such a possibility is IMO quite remote.
-</p>
-
-<p>
-Alternate Suggestion from Howard Hinnant, c++std-lib-7780:
-</p>
-
-<p>
-This is something of a nit, but I'm wondering if streamoff wouldn't be a
-better choice than streamsize. The argument to pbump and gbump MUST be
-signed. But the standard has this to say about streamsize
-(27.4.1/2/Footnote):
-</p>
-
-<blockquote><p>
- [Footnote: streamsize is used in most places where ISO C would use
- size_t. Most of the uses of streamsize could use size_t, except for
- the strstreambuf constructors, which require negative values. It
- should probably be the signed type corresponding to size_t (which is
- what Posix.2 calls ssize_t). --- end footnote]
-</p></blockquote>
-
-<p>
-This seems a little weak for the argument to pbump and gbump. Should we
-ever really get rid of strstream, this footnote might go with it, along
-with the reason to make streamsize signed.
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes this change is too big for now. We may wish to
-reconsider this for a future revision of the standard. One
-possibility is overloading pbump, rather than changing the
-signature.</p>
-<p><i>[
-[2006-05-04: Reopened at the request of Chris (Krzysztof ?elechowski)]
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="290"></a>290. Requirements to for_each and its function object</h3>
-<p><b>Section:</b> 25.1.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The specification of the for_each algorithm does not have a
-"Requires" section, which means that there are no
-restrictions imposed on the function object whatsoever. In essence it
-means that I can provide any function object with arbitrary side
-effects and I can still expect a predictable result. In particular I
-can expect that the function object is applied exactly last - first
-times, which is promised in the "Complexity" section.
-</p>
-
-<p>I don't see how any implementation can give such a guarantee
-without imposing requirements on the function object.
-</p>
-
-<p>Just as an example: consider a function object that removes
-elements from the input sequence. In that case, what does the
-complexity guarantee (applies f exactly last - first times) mean?
-</p>
-
-<p>One can argue that this is obviously a nonsensical application and
-a theoretical case, which unfortunately it isn't. I have seen
-programmers shooting themselves in the foot this way, and they did not
-understand that there are restrictions even if the description of the
-algorithm does not say so.
-</p>
-<p><i>[Lillehammer: This is more general than for_each. We don't want
- the function object in transform invalidiating iterators
- either. There should be a note somewhere in clause 17 (17, not 25)
- saying that user code operating on a range may not invalidate
- iterators unless otherwise specified. Bill will provide wording.]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="299"></a>299. Incorrect return types for iterator dereference</h3>
-<p><b>Section:</b> 24.1.4 [bidirectional.iterators], 24.1.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> John Potter <b>Date:</b> 2001-01-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In section 24.1.4 [bidirectional.iterators],
-Table 75 gives the return type of *r-- as convertible to T. This is
-not consistent with Table 74 which gives the return type of *r++ as
-T&amp;. *r++ = t is valid while *r-- = t is invalid.
-</p>
-
-<p>
-In section 24.1.5 [random.access.iterators],
-Table 76 gives the return type of a[n] as convertible to T. This is
-not consistent with the semantics of *(a + n) which returns T&amp; by
-Table 74. *(a + n) = t is valid while a[n] = t is invalid.
-</p>
-
-<p>
-Discussion from the Copenhagen meeting: the first part is
-uncontroversial. The second part, operator[] for Random Access
-Iterators, requires more thought. There are reasonable arguments on
-both sides. Return by value from operator[] enables some potentially
-useful iterators, e.g. a random access "iota iterator" (a.k.a
-"counting iterator" or "int iterator"). There isn't any obvious way
-to do this with return-by-reference, since the reference would be to a
-temporary. On the other hand, <tt>reverse_iterator</tt> takes an
-arbitrary Random Access Iterator as template argument, and its
-operator[] returns by reference. If we decided that the return type
-in Table 76 was correct, we would have to change
-<tt>reverse_iterator</tt>. This change would probably affect user
-code.
-</p>
-
-<p>
-History: the contradiction between <tt>reverse_iterator</tt> and the
-Random Access Iterator requirements has been present from an early
-stage. In both the STL proposal adopted by the committee
-(N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by
-Stepanov and Lee), the Random Access Iterator requirements say that
-operator[]'s return value is "convertible to T". In N0527
-reverse_iterator's operator[] returns by value, but in HPL-95-11
-(R.1), and in the STL implementation that HP released to the public,
-reverse_iterator's operator[] returns by reference. In 1995, the
-standard was amended to reflect the contents of HPL-95-11 (R.1). The
-original intent for operator[] is unclear.
-</p>
-
-<p>
-In the long term it may be desirable to add more fine-grained
-iterator requirements, so that access method and traversal strategy
-can be decoupled. (See "Improved Iterator Categories and
-Requirements", N1297 = 01-0011, by Jeremy Siek.) Any decisions
-about issue 299 should keep this possibility in mind.
-</p>
-
-<p>Further discussion: I propose a compromise between John Potter's
-resolution, which requires <tt>T&amp;</tt> as the return type of
-<tt>a[n]</tt>, and the current wording, which requires convertible to
-<tt>T</tt>. The compromise is to keep the convertible to <tt>T</tt>
-for the return type of the expression <tt>a[n]</tt>, but to also add
-<tt>a[n] = t</tt> as a valid expression. This compromise "saves" the
-common case uses of random access iterators, while at the same time
-allowing iterators such as counting iterator and caching file
-iterators to remain random access iterators (iterators where the
-lifetime of the object returned by <tt>operator*()</tt> is tied to the
-lifetime of the iterator).
-</p>
-
-<p>
-Note that the compromise resolution necessitates a change to
-<tt>reverse_iterator</tt>. It would need to use a proxy to support
-<tt>a[n] = t</tt>.
-</p>
-
-<p>
-Note also there is one kind of mutable random access iterator that
-will no longer meet the new requirements. Currently, iterators that
-return an r-value from <tt>operator[]</tt> meet the requirements for a
-mutable random access iterartor, even though the expression <tt>a[n] =
-t</tt> will only modify a temporary that goes away. With this proposed
-resolution, <tt>a[n] = t</tt> will be required to have the same
-operational semantics as <tt>*(a + n) = t</tt>.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-In section 24.1.4 [lib.bidirectdional.iterators], change the return
-type in table 75 from "convertible to <tt>T</tt>" to
-<tt>T&amp;</tt>.
-</p>
-
-<p>
-In section 24.1.5 [lib.random.access.iterators], change the
-operational semantics for <tt>a[n]</tt> to " the r-value of
-<tt>a[n]</tt> is equivalent to the r-value of <tt>*(a +
-n)</tt>". Add a new row in the table for the expression <tt>a[n] = t</tt>
-with a return type of convertible to <tt>T</tt> and operational semantics of
-<tt>*(a + n) = t</tt>.
-</p>
-
-<p><i>[Lillehammer: Real problem, but should be addressed as part of
- iterator redesign]</i></p>
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="309"></a>309. Does sentry catch exceptions?</h3>
-<p><b>Section:</b> 27.6 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-19</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The descriptions of the constructors of basic_istream&lt;&gt;::sentry
-(27.6.1.1.3 [istream::sentry]) and basic_ostream&lt;&gt;::sentry
-(27.6.2.4 [ostream::sentry]) do not explain what the functions do in
-case an exception is thrown while they execute. Some current
-implementations allow all exceptions to propagate, others catch them
-and set ios_base::badbit instead, still others catch some but let
-others propagate.
-</p>
-
-<p>
-The text also mentions that the functions may call setstate(failbit)
-(without actually saying on what object, but presumably the stream
-argument is meant). That may have been fine for
-basic_istream&lt;&gt;::sentry prior to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>, since
-the function performs an input operation which may fail. However,
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a> amends 27.6.1.1.3 [istream::sentry], p2 to
-clarify that the function should actually call setstate(failbit |
-eofbit), so the sentence in p3 is redundant or even somewhat
-contradictory.
-</p>
-
-<p>
-The same sentence that appears in 27.6.2.4 [ostream::sentry], p3
-doesn't seem to be very meaningful for basic_istream&lt;&gt;::sentry
-which performs no input. It is actually rather misleading since it
-would appear to guide library implementers to calling
-setstate(failbit) when os.tie()-&gt;flush(), the only called function,
-throws an exception (typically, it's badbit that's set in response to
-such an event).
-</p>
-
-<p><b>Additional comments from Martin, who isn't comfortable with the
- current proposed resolution</b> (see c++std-lib-11530)</p>
-
-<p>
-The istream::sentry ctor says nothing about how the function
-deals with exemptions (27.6.1.1.2, p1 says that the class is
-responsible for doing "exception safe"(*) prefix and suffix
-operations but it doesn't explain what level of exception
-safety the class promises to provide). The mockup example
-of a "typical implementation of the sentry ctor" given in
-27.6.1.1.2, p6, removed in ISO/IEC 14882:2003, doesn't show
-exception handling, either. Since the ctor is not classified
-as a formatted or unformatted input function, the text in
-27.6.1.1, p1 through p4 does not apply. All this would seem
-to suggest that the sentry ctor should not catch or in any
-way handle exceptions thrown from any functions it may call.
-Thus, the typical implementation of an istream extractor may
-look something like [1].
-</p>
-
-<p>
-The problem with [1] is that while it correctly sets ios::badbit
-if an exception is thrown from one of the functions called from
-the sentry ctor, if the sentry ctor reaches EOF while extracting
-whitespace from a stream that has eofbit or failbit set in
-exceptions(), it will cause an ios::failure to be thrown, which
-will in turn cause the extractor to set ios::badbit.
-</p>
-
-<p>
-The only straightforward way to prevent this behavior is to
-move the definition of the sentry object in the extractor
-above the try block (as suggested by the example in 22.2.8,
-p9 and also indirectly supported by 27.6.1.3, p1). See [2].
-But such an implementation will allow exceptions thrown from
-functions called from the ctor to freely propagate to the
-caller regardless of the setting of ios::badbit in the stream
-object's exceptions().
-</p>
-
-<p>
-So since neither [1] nor [2] behaves as expected, the only
-possible solution is to have the sentry ctor catch exceptions
-thrown from called functions, set badbit, and propagate those
-exceptions if badbit is also set in exceptions(). (Another
-solution exists that deals with both kinds of sentries, but
-the code is non-obvious and cumbersome -- see [3].)
-</p>
-
-<p>
-Please note that, as the issue points out, current libraries
-do not behave consistently, suggesting that implementors are
-not quite clear on the exception handling in istream::sentry,
-despite the fact that some LWG members might feel otherwise.
-(As documented by the parenthetical comment here:
-http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html#309)
-</p>
-
-<p>
-Also please note that those LWG members who in Copenhagen
-felt that "a sentry's constructor should not catch exceptions,
-because sentries should only be used within (un)formatted input
-functions and that exception handling is the responsibility of
-those functions, not of the sentries," as noted here
-http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1310.html#309
-would in effect be either arguing for the behavior described
-in [1] or for extractors implemented along the lines of [3].
-</p>
-
-<p>
-The original proposed resolution (Revision 25 of the issues
-list) clarifies the role of the sentry ctor WRT exception
-handling by making it clear that extractors (both library
-or user-defined) should be implemented along the lines of
-[2] (as opposed to [1]) and that no exception thrown from
-the callees should propagate out of either function unless
-badbit is also set in exceptions().
-</p>
-
-
-<p>[1] Extractor that catches exceptions thrown from sentry:</p>
-
-<blockquote>
-<pre>struct S { long i; };
-
-istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
-{
- ios::iostate err = ios::goodbit;
- try {
- const istream::sentry guard (strm, false);
- if (guard) {
- use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
- .get (istreambuf_iterator&lt;char&gt;(strm),
- istreambuf_iterator&lt;char&gt;(),
- strm, err, s.i);
- }
- }
- catch (...) {
- bool rethrow;
- try {
- strm.setstate (ios::badbit);
- rethrow = false;
- }
- catch (...) {
- rethrow = true;
- }
- if (rethrow)
- throw;
- }
- if (err)
- strm.setstate (err);
- return strm;
-}
-</pre>
-</blockquote>
-
-<p>[2] Extractor that propagates exceptions thrown from sentry:</p>
-
-<blockquote>
-<pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
-{
- istream::sentry guard (strm, false);
- if (guard) {
- ios::iostate err = ios::goodbit;
- try {
- use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
- .get (istreambuf_iterator&lt;char&gt;(strm),
- istreambuf_iterator&lt;char&gt;(),
- strm, err, s.i);
- }
- catch (...) {
- bool rethrow;
- try {
- strm.setstate (ios::badbit);
- rethrow = false;
- }
- catch (...) {
- rethrow = true;
- }
- if (rethrow)
- throw;
- }
- if (err)
- strm.setstate (err);
- }
- return strm;
-}
-</pre>
-</blockquote>
-
-<p>
-[3] Extractor that catches exceptions thrown from sentry
-but doesn't set badbit if the exception was thrown as a
-result of a call to strm.clear().
-</p>
-
-<blockquote>
-<pre>istream&amp; operator&gt;&gt; (istream &amp;strm, S &amp;s)
-{
- const ios::iostate state = strm.rdstate ();
- const ios::iostate except = strm.exceptions ();
- ios::iostate err = std::ios::goodbit;
- bool thrown = true;
- try {
- const istream::sentry guard (strm, false);
- thrown = false;
- if (guard) {
- use_facet&lt;num_get&lt;char&gt; &gt;(strm.getloc ())
- .get (istreambuf_iterator&lt;char&gt;(strm),
- istreambuf_iterator&lt;char&gt;(),
- strm, err, s.i);
- }
- }
- catch (...) {
- if (thrown &amp;&amp; state &amp; except)
- throw;
- try {
- strm.setstate (ios::badbit);
- thrown = false;
- }
- catch (...) {
- thrown = true;
- }
- if (thrown)
- throw;
- }
- if (err)
- strm.setstate (err);
-
- return strm;
-}
-</pre>
-</blockquote>
-
-<p>
-[Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.
-</p>
-
-<p>
-[Pre-Portland] A relevant newsgroup post:
-</p>
-
-<p>
-The current proposed resolution of issue #309
-(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is
-unacceptable. I write commerical software and coding around this
-makes my code ugly, non-intuitive, and requires comments referring
-people to this very issue. Following is the full explanation of my
-experience.
-</p>
-<p>
-In the course of writing software for commercial use, I constructed
-std::ifstream's based on user-supplied pathnames on typical POSIX
-systems.
-</p>
-<p>
-It was expected that some files that opened successfully might not read
-successfully -- such as a pathname which actually refered to a
-directory. Intuitively, I expected the streambuffer underflow() code
-to throw an exception in this situation, and recent implementations of
-libstdc++'s basic_filebuf do just that (as well as many of my own
-custom streambufs).
-</p>
-<p>
-I also intuitively expected that the istream code would convert these
-exceptions to the "badbit' set on the stream object, because I had not
-requested exceptions. I refer to 27.6.1.1. P4.
-</p>
-<p>
-However, this was not the case on at least two implementations -- if
-the first thing I did with an istream was call operator&gt;&gt;( T&amp; ) for T
-among the basic arithmetic types and std::string. Looking further I
-found that the sentry's constructor was invoking the exception when it
-pre-scanned for whitespace, and the extractor function (operator&gt;&gt;())
-was not catching exceptions in this situation.
-</p>
-<p>
-So, I was in a situation where setting 'noskipws' would change the
-istream's behavior even though no characters (whitespace or not) could
-ever be successfully read.
-</p>
-<p>
-Also, calling .peek() on the istream before calling the extractor()
-changed the behavior (.peek() had the effect of setting the badbit
-ahead of time).
-</p>
-<p>
-I found this all to be so inconsistent and inconvenient for me and my
-code design, that I filed a bugzilla entry for libstdc++. I was then
-told that the bug cannot be fixed until issue #309 is resolved by the
-committee.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG agrees there is minor variation between implementations,
- but believes that it doesn't matter. This is a rarely used corner
- case. There is no evidence that this has any commercial importance
- or that it causes actual portability problems for customers trying
- to write code that runs on multiple implementations.</p>
-
-
-
-
-
-<hr>
-<h3><a name="342"></a>342. seek and eofbit</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-10-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>I think we have a defect.</p>
-
-<p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the
-description of seekg in 27.6.1.3 [istream.unformatted] paragraph 38 now looks
-like:</p>
-
-<blockquote><p>
-Behaves as an unformatted input function (as described in 27.6.1.3,
-paragraph 1), except that it does not count the number of characters
-extracted and does not affect the value returned by subsequent calls to
-gcount(). After constructing a sentry object, if fail() != true,
-executes rdbuf()-&gt;pubseekpos( pos).
-</p></blockquote>
-
-<p>And according to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> which is also now a dr,
-27.6.1.3, paragraph 1 looks like:</p>
-
-<blockquote><p>
-Each unformatted input function begins execution by constructing an
-object of class sentry with the default argument noskipws (second)
-argument true. If the sentry object returns true, when converted to a
-value of type bool, the function endeavors to obtain the requested
-input. Otherwise, if the sentry constructor exits by throwing an
-exception or if the sentry object returns false, when converted to a
-value of type bool, the function returns without attempting to obtain
-any input. In either case the number of extracted characters is set to
-0; unformatted input functions taking a character array of non-zero
-size as an argument shall also store a null character (using charT())
-in the first location of the array. If an exception is thrown during
-input then ios::badbit is turned on in *this'ss error state. If
-(exception()&amp;badbit)!= 0 then the exception is rethrown. It also counts
-the number of characters extracted. If no exception has been thrown it
-ends by storing the count in a member object and returning the value
-specified. In any event the sentry object is destroyed before leaving
-the unformatted input function.
-</p></blockquote>
-
-<p>And finally 27.6.1.1.2/5 says this about sentry:</p>
-
-<blockquote><p>
-If, after any preparation is completed, is.good() is true, ok_ != false
-otherwise, ok_ == false.
-</p></blockquote>
-
-<p>
-So although the seekg paragraph says that the operation proceeds if
-!fail(), the behavior of unformatted functions says the operation
-proceeds only if good(). The two statements are contradictory when only
-eofbit is set. I don't think the current text is clear which condition
-should be respected.
-</p>
-
-<p><b>Further discussion from Redmond:</b></p>
-
-<p>PJP: It doesn't seem quite right to say that <tt>seekg</tt> is
-"unformatted". That makes specific claims about sentry that
-aren't quite appropriate for seeking, which has less fragile failure
-modes than actual input. If we do really mean that it's unformatted
-input, it should behave the same way as other unformatted input. On
-the other hand, "principle of least surprise" is that seeking from EOF
-ought to be OK.</p>
-
-<p>
-Pre-Berlin: Paolo points out several problems with the proposed resolution in
-Ready state:
-</p>
-
-<ul>
-<li>It should apply to both overloads of seekg.</li>
-<li>tellg has similar issues, except that it should not call clear().</li>
-<li>The point about clear() seems to apply to seekp().</li>
-<li>Depending on the outcome of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#419">419</a>
-if the sentry
-sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
-you can never seek away from the end of stream.</li>
-</ul>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Change 27.6.1.3 [istream.unformatted] to:</p>
-<blockquote><p>
-Behaves as an unformatted input function (as described in 27.6.1.3,
-paragraph 1), except that it does not count the number of characters
-extracted, does not affect the value returned by subsequent calls to
-gcount(), and does not examine the value returned by the sentry
-object. After constructing a sentry object, if <tt>fail() !=
-true</tt>, executes <tt>rdbuf()-&gt;pubseekpos(pos)</tt>. In
-case of success, the function calls clear().
-In case of failure, the function calls <tt>setstate(failbit)</tt>
-(which may throw <tt>ios_base::failure</tt>).
-</p></blockquote>
-
-<p><i>[Lillehammer: Matt provided wording.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>In C, fseek does clear EOF. This is probably what most users would
- expect. We agree that having eofbit set should not deter a seek,
- and that a successful seek should clear eofbit. Note
- that <tt>fail()</tt> is true only if <tt>failbit</tt>
- or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
- than <tt>good()</tt>, satisfies this goal.</p>
-
-
-
-
-
-<hr>
-<h3><a name="343"></a>343. Unspecified library header dependencies</h3>
-<p><b>Section:</b> 21 [strings], 23 [containers], 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-10-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The synopses of the C++ library headers clearly show which names are
-required to be defined in each header. Since in order to implement the
-classes and templates defined in these headers declarations of other
-templates (but not necessarily their definitions) are typically
-necessary the standard in 17.4.4, p1 permits library implementers to
-include any headers needed to implement the definitions in each header.
-</p>
-
-<p>
-For instance, although it is not explicitly specified in the synopsis of
-&lt;string&gt;, at the point of definition of the std::basic_string template
-the declaration of the std::allocator template must be in scope. All
-current implementations simply include &lt;memory&gt; from within &lt;string&gt;,
-either directly or indirectly, to bring the declaration of
-std::allocator into scope.
-</p>
-
-<p>
-Additionally, however, some implementation also include &lt;istream&gt; and
-&lt;ostream&gt; at the top of &lt;string&gt; to bring the declarations of
-std::basic_istream and std::basic_ostream into scope (which are needed
-in order to implement the string inserter and extractor operators
-(21.3.7.9 [lib.string.io])). Other implementations only include
-&lt;iosfwd&gt;, since strictly speaking, only the declarations and not the
-full definitions are necessary.
-</p>
-
-<p>
-Obviously, it is possible to implement &lt;string&gt; without actually
-providing the full definitions of all the templates std::basic_string
-uses (std::allocator, std::basic_istream, and std::basic_ostream).
-Furthermore, not only is it possible, doing so is likely to have a
-positive effect on compile-time efficiency.
-</p>
-
-<p>
-But while it may seem perfectly reasonable to expect a program that uses
-the std::basic_string insertion and extraction operators to also
-explicitly include &lt;istream&gt; or &lt;ostream&gt;, respectively, it doesn't seem
-reasonable to also expect it to explicitly include &lt;memory&gt;. Since
-what's reasonable and what isn't is highly subjective one would expect
-the standard to specify what can and what cannot be assumed.
-Unfortunately, that isn't the case.
-</p>
-
-<p>The examples below demonstrate the issue.</p>
-
-<p>Example 1:</p>
-
-<p>It is not clear whether the following program is complete:</p>
-
-<pre>#include &lt;string&gt;
-
-extern std::basic_ostream&lt;char&gt; &amp;strm;
-
-int main () {
- strm &lt;&lt; std::string ("Hello, World!\n");
-}
-</pre>
-
-<p>or whether one must explicitly include &lt;memory&gt; or
-&lt;ostream&gt; (or both) in addition to &lt;string&gt; in order for
-the program to compile.</p>
-
-
-<p>Example 2:</p>
-
-<p>Similarly, it is unclear whether the following program is complete:</p>
-
-<pre>#include &lt;istream&gt;
-
-extern std::basic_iostream&lt;char&gt; &amp;strm;
-
-int main () {
- strm &lt;&lt; "Hello, World!\n";
-}
-</pre>
-
-<p>
-or whether one needs to explicitly include &lt;ostream&gt;, and
-perhaps even other headers containing the definitions of other
-required templates:</p>
-
-<pre>#include &lt;ios&gt;
-#include &lt;istream&gt;
-#include &lt;ostream&gt;
-#include &lt;streambuf&gt;
-
-extern std::basic_iostream&lt;char&gt; &amp;strm;
-
-int main () {
- strm &lt;&lt; "Hello, World!\n";
-}
-</pre>
-
-<p>Example 3:</p>
-
-<p>Likewise, it seems unclear whether the program below is complete:</p>
-<pre>#include &lt;iterator&gt;
-
-bool foo (std::istream_iterator&lt;int&gt; a, std::istream_iterator&lt;int&gt; b)
-{
- return a == b;
-}
-
-int main () { }
-</pre>
-
-<p>or whether one should be required to include &lt;istream&gt;.</p>
-
-<p>There are many more examples that demonstrate this lack of a
-requirement. I believe that in a good number of cases it would be
-unreasonable to require that a program explicitly include all the
-headers necessary for a particular template to be specialized, but I
-think that there are cases such as some of those above where it would
-be desirable to allow implementations to include only as much as
-necessary and not more.</p>
-
-<p><i>[
-post Bellevue:
-]</i></p>
-
-
-<blockquote>
-Position taken in prior reviews is that the idea of a table of header
-dependencies is a good one. Our view is that a full paper is needed to
-do justice to this, and we've made that recommendation to the issue
-author.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-For every C++ library header, supply a minimum set of other C++ library
-headers that are required to be included by that header. The proposed
-list is below (C++ headers for C Library Facilities, table 12 in
-17.4.1.2, p3, are omitted):
-</p>
-
-<pre>+------------+--------------------+
-| C++ header |required to include |
-+============+====================+
-|&lt;algorithm&gt; | |
-+------------+--------------------+
-|&lt;bitset&gt; | |
-+------------+--------------------+
-|&lt;complex&gt; | |
-+------------+--------------------+
-|&lt;deque&gt; |&lt;memory&gt; |
-+------------+--------------------+
-|&lt;exception&gt; | |
-+------------+--------------------+
-|&lt;fstream&gt; |&lt;ios&gt; |
-+------------+--------------------+
-|&lt;functional&gt;| |
-+------------+--------------------+
-|&lt;iomanip&gt; |&lt;ios&gt; |
-+------------+--------------------+
-|&lt;ios&gt; |&lt;streambuf&gt; |
-+------------+--------------------+
-|&lt;iosfwd&gt; | |
-+------------+--------------------+
-|&lt;iostream&gt; |&lt;istream&gt;, &lt;ostream&gt;|
-+------------+--------------------+
-|&lt;istream&gt; |&lt;ios&gt; |
-+------------+--------------------+
-|&lt;iterator&gt; | |
-+------------+--------------------+
-|&lt;limits&gt; | |
-+------------+--------------------+
-|&lt;list&gt; |&lt;memory&gt; |
-+------------+--------------------+
-|&lt;locale&gt; | |
-+------------+--------------------+
-|&lt;map&gt; |&lt;memory&gt; |
-+------------+--------------------+
-|&lt;memory&gt; | |
-+------------+--------------------+
-|&lt;new&gt; |&lt;exception&gt; |
-+------------+--------------------+
-|&lt;numeric&gt; | |
-+------------+--------------------+
-|&lt;ostream&gt; |&lt;ios&gt; |
-+------------+--------------------+
-|&lt;queue&gt; |&lt;deque&gt; |
-+------------+--------------------+
-|&lt;set&gt; |&lt;memory&gt; |
-+------------+--------------------+
-|&lt;sstream&gt; |&lt;ios&gt;, &lt;string&gt; |
-+------------+--------------------+
-|&lt;stack&gt; |&lt;deque&gt; |
-+------------+--------------------+
-|&lt;stdexcept&gt; | |
-+------------+--------------------+
-|&lt;streambuf&gt; |&lt;ios&gt; |
-+------------+--------------------+
-|&lt;string&gt; |&lt;memory&gt; |
-+------------+--------------------+
-|&lt;strstream&gt; | |
-+------------+--------------------+
-|&lt;typeinfo&gt; |&lt;exception&gt; |
-+------------+--------------------+
-|&lt;utility&gt; | |
-+------------+--------------------+
-|&lt;valarray&gt; | |
-+------------+--------------------+
-|&lt;vector&gt; |&lt;memory&gt; |
-+------------+--------------------+
-</pre>
-
-
-<p><b>Rationale:</b></p>
-<p>The portability problem is real. A program that works correctly on
-one implementation might fail on another, because of different header
-dependencies. This problem was understood before the standard was
-completed, and it was a conscious design choice.</p>
-<p>One possible way to deal with this, as a library extension, would
-be an &lt;all&gt; header.</p>
-
-<p>
-Hinnant: It's time we dealt with this issue for C++0X. Reopened.
-</p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="382"></a>382. codecvt do_in/out result</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-08-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It seems that the descriptions of codecvt do_in() and do_out() leave
-sufficient room for interpretation so that two implementations of
-codecvt may not work correctly with the same filebuf. Specifically,
-the following seems less than adequately specified:
-</p>
-
-<ol>
-<li>
- the conditions under which the functions terminate
-</li>
-<li>
- precisely when the functions return ok
-</li>
-<li>
- precisely when the functions return partial
-</li>
-<li>
- the full set of conditions when the functions return error
-</li>
-</ol>
-
-<ol>
-<li>
- 22.2.1.4.2 [locale.codecvt.virtuals], p2 says this about the effects of the
- function: ...Stops if it encounters a character it cannot
- convert... This assumes that there *is* a character to
- convert. What happens when there is a sequence that doesn't form a
- valid source character, such as an unassigned or invalid UNICODE
- character, or a sequence that cannot possibly form a character
- (e.g., the sequence "\xc0\xff" in UTF-8)?
-</li>
-<li>
- Table 53 says that the function returns codecvt_base::ok
- to indicate that the function(s) "completed the conversion."
- Suppose that the source sequence is "\xc0\x80" in UTF-8,
- with from pointing to '\xc0' and (from_end==from + 1).
- It is not clear whether the return value should be ok
- or partial (see below).
-</li>
-<li>
- Table 53 says that the function returns codecvt_base::partial
- if "not all source characters converted." With the from pointers
- set up the same way as above, it is not clear whether the return
- value should be partial or ok (see above).
-</li>
-<li>
- Table 53, in the row describing the meaning of error mistakenly
- refers to a "from_type" character, without the symbol from_type
- having been defined. Most likely, the word "source" character
- is intended, although that is not sufficient. The functions
- may also fail when they encounter an invalid source sequence
- that cannot possibly form a valid source character (e.g., as
- explained in bullet 1 above).
-</li>
-</ol>
-<p>
-Finally, the conditions described at the end of 22.2.1.4.2 [locale.codecvt.virtuals], p4 don't seem to be possible:
-</p>
-<blockquote><p>
- "A return value of partial, if (from_next == from_end),
- indicates that either the destination sequence has not
- absorbed all the available destination elements, or that
- additional source elements are needed before another
- destination element can be produced."
-</p></blockquote>
-<p>
-If the value is partial, it's not clear to me that (from_next
-==from_end) could ever hold if there isn't enough room
-in the destination buffer. In order for (from_next==from_end) to
-hold, all characters in that range must have been successfully
-converted (according to 22.2.1.4.2 [locale.codecvt.virtuals], p2) and since there are no
-further source characters to convert, no more room in the
-destination buffer can be needed.
-</p>
-<p>
-It's also not clear to me that (from_next==from_end) could ever
-hold if additional source elements are needed to produce another
-destination character (not element as incorrectly stated in the
-text). partial is returned if "not all source characters have
-been converted" according to Table 53, which also implies that
-(from_next==from) does NOT hold.
-</p>
-<p>
-Could it be that the intended qualifying condition was actually
-(from_next != from_end), i.e., that the sentence was supposed
-to read
-</p>
-<blockquote><p>
- "A return value of partial, if (from_next != from_end),..."
-</p></blockquote>
-<p>
-which would make perfect sense, since, as far as I understand it,
-partial can only occur if (from_next != from_end)?
-</p>
-<p><i>[Lillehammer: Defer for the moment, but this really needs to be
- fixed. Right now, the description of codecvt is too vague for it to
- be a useful contract between providers and clients of codecvt
- facets. (Note that both vendors and users can be both providers and
- clients of codecvt facets.) The major philosophical issue is whether
- the standard should only describe mappings that take a single wide
- character to multiple narrow characters (and vice versa), or whether
- it should describe fully general N-to-M conversions. When the
- original standard was written only the former was contemplated, but
- today, in light of the popularity of utf8 and utf16, that doesn't
- seem sufficient for C++0x. Bill supports general N-to-M conversions;
- we need to make sure Martin and Howard agree.]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-<hr>
-<h3><a name="387"></a>387. std::complex over-encapsulated</h3>
-<p><b>Section:</b> 26.3 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The absence of explicit description of std::complex&lt;T&gt; layout
-makes it imposible to reuse existing software developed in traditional
-languages like Fortran or C with unambigous and commonly accepted
-layout assumptions. There ought to be a way for practitioners to
-predict with confidence the layout of std::complex&lt;T&gt; whenever T
-is a numerical datatype. The absence of ways to access individual
-parts of a std::complex&lt;T&gt; object as lvalues unduly promotes
-severe pessimizations. For example, the only way to change,
-independently, the real and imaginary parts is to write something like
-</p>
-
-<pre>complex&lt;T&gt; z;
-// ...
-// set the real part to r
-z = complex&lt;T&gt;(r, z.imag());
-// ...
-// set the imaginary part to i
-z = complex&lt;T&gt;(z.real(), i);
-</pre>
-
-<p>
-At this point, it seems appropriate to recall that a complex number
-is, in effect, just a pair of numbers with no particular invariant to
-maintain. Existing practice in numerical computations has it that a
-complex number datatype is usually represented by Cartesian
-coordinates. Therefore the over-encapsulation put in the specification
-of std::complex&lt;&gt; is not justified.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add the following requirements to 26.3 [complex.numbers] as 26.3/4:</p>
-<blockquote>
-<p>If z is an lvalue expression of type cv std::complex&lt;T&gt; then</p>
-
-<ul>
-<li>the expression reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)
-is well-formed; and</li>
-<li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[0]designates the
-real part of z; and</li>
-<li>reinterpret_cast&lt;cv T(&amp;)[2]&gt;(z)[1]designates the
-imaginary part of z.</li>
-</ul>
-
-<p>
-Moreover, if a is an expression of pointer type cv complex&lt;T&gt;*
-and the expression a[i] is well-defined for an integer expression
-i then:
-</p>
-
-<ul>
-<li>reinterpret_cast&lt;cv T*&gt;(a)[2*i] designates the real
-part of a[i]; and</li>
-<li>reinterpret_cast&lt;cv T*&gt;(a)[2*i+1] designates the
-imaginary part of a[i].</li>
-</ul>
-</blockquote>
-
-<p>
-In 26.3.2 [complex] and 26.3.3 [complex.special] add the following member functions
-(changing <tt>T</tt> to concrete types as appropriate for the specializations).
-</p>
-
-<blockquote><pre>void real(T);
-void imag(T);
-</pre></blockquote>
-
-<p>
-Add to 26.3.4 [complex.members]
-</p>
-
-<blockquote>
-<pre>T real() const;
-</pre>
-<blockquote>
-<i>Returns:</i> the value of the real component
-</blockquote>
-<pre>void real(T val);
-</pre>
-<blockquote>
-Assigns val to the real component.
-</blockquote>
-<pre>T imag() const;
-</pre>
-<blockquote>
-<i>Returns:</i> the value of the imaginary component
-</blockquote>
-<pre>void imag(T val);
-</pre>
-<blockquote>
-Assigns val to the imaginary component.
-</blockquote>
-</blockquote>
-
-<p><i>[Kona: The layout guarantee is absolutely necessary for C
- compatibility. However, there was disagreement about the other part
- of this proposal: retrieving elements of the complex number as
- lvalues. An alternative: continue to have real() and imag() return
- rvalues, but add set_real() and set_imag(). Straw poll: return
- lvalues - 2, add setter functions - 5. Related issue: do we want
- reinterpret_cast as the interface for converting a complex to an
- array of two reals, or do we want to provide a more explicit way of
- doing it? Howard will try to resolve this issue for the next
- meeting.]</i></p>
-
-
-<p><i>[pre-Sydney: Howard summarized the options in n1589.]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Second half of proposed wording replaced and moved to Ready.
-</blockquote>
-
-<p><i>[
-Pre-Sophia Antipolis, Howard adds:
-]</i></p>
-
-
-<blockquote>
-Added the members to 26.3.3 [complex.special] and changed from Ready to Review.
-</blockquote>
-
-<p><i>[
-Post-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-Moved from WP back to Ready so that the "and 26.3.3 [complex.special]" in the proposed
-resolution can be officially applied.
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes that C99 compatibility would be enough
-justification for this change even without other considerations. All
-existing implementations already have the layout proposed here.</p>
-
-
-
-
-
-<hr>
-<h3><a name="394"></a>394. behavior of formatted output on failure</h3>
-<p><b>Section:</b> 27.6.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-12-27</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There is a contradiction in Formatted output about what bit is
-supposed to be set if the formatting fails. On sentence says it's
-badbit and another that it's failbit.
-</p>
-<p>
-27.6.2.5.1, p1 says in the Common Requirements on Formatted output
-functions:
-</p>
-<pre> ... If the generation fails, then the formatted output function
- does setstate(ios::failbit), which might throw an exception.
-</pre>
-<p>
-27.6.2.5.2, p1 goes on to say this about Arithmetic Inserters:
-</p>
-<p>
- ... The formatting conversion occurs as if it performed the
- following code fragment:
-</p>
-<pre> bool failed =
- use_facet&lt;num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt;
- &gt; &gt;
- (getloc()).put(*this, *this, fill(), val). failed();
-
- ... If failed is true then does setstate(badbit) ...
-</pre>
-<p>
-The original intent of the text, according to Jerry Schwarz (see
-c++std-lib-10500), is captured in the following paragraph:
-</p>
-<p>
-In general "badbit" should mean that the stream is unusable because
-of some underlying failure, such as disk full or socket closure;
-"failbit" should mean that the requested formatting wasn't possible
-because of some inconsistency such as negative widths. So typically
-if you clear badbit and try to output something else you'll fail
-again, but if you clear failbit and try to output something else
-you'll succeed.
-</p>
-<p>
-In the case of the arithmetic inserters, since num_put cannot
-report failure by any means other than exceptions (in response
-to which the stream must set badbit, which prevents the kind of
-recoverable error reporting mentioned above), the only other
-detectable failure is if the iterator returned from num_put
-returns true from failed().
-</p>
-<p>
-Since that can only happen (at least with the required iostream
-specializations) under such conditions as the underlying failure
-referred to above (e.g., disk full), setting badbit would seem
-to be the appropriate response (indeed, it is required in
-27.6.2.5.2, p1). It follows that failbit can never be directly
-set by the arithmetic (it can only be set by the sentry object
-under some unspecified conditions).
-</p>
-<p>
-The situation is different for other formatted output functions
-which can fail as a result of the streambuf functions failing
-(they may do so by means other than exceptions), and which are
-then required to set failbit.
-</p>
-<p>
-The contradiction, then, is that ostream::operator&lt;&lt;(int) will
-set badbit if the disk is full, while operator&lt;&lt;(ostream&amp;,
-char) will set failbit under the same conditions. To make the behavior
-consistent, the Common requirements sections for the Formatted output
-functions should be changed as proposed below.
-</p>
-<p><i>[Kona: There's agreement that this is a real issue. What we
- decided at Kona: 1. An error from the buffer (which can be detected
- either directly from streambuf's member functions or by examining a
- streambuf_iterator) should always result in badbit getting set.
- 2. There should never be a circumstance where failbit gets set.
- That represents a formatting error, and there are no circumstances
- under which the output facets are specified as signaling a
- formatting error. (Even more so for string output that for numeric
- because there's nothing to format.) If we ever decide to make it
- possible for formatting errors to exist then the facets can signal
- the error directly, and that should go in clause 22, not clause 27.
- 3. The phrase "if generation fails" is unclear and should be
- eliminated. It's not clear whether it's intended to mean a buffer
- error (e.g. a full disk), a formatting error, or something else.
- Most people thought it was supposed to refer to buffer errors; if
- so, we should say so. Martin will provide wording.]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="396"></a>396. what are characters zero and one</h3>
-<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
-having the value of 0 or 1 but there is no definition of what
-that means for charT other than char and wchar_t. And even for
-those two types, the values 0 and 1 are not actually what is
-intended -- the values '0' and '1' are. This, along with the
-converse problem in the description of to_string() in 23.3.5.2,
-p33, looks like a defect remotely related to DR 303.
- </p>
- <p>
-http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
- </p>
- <pre>23.3.5.1:
- -6- An element of the constructed string has value zero if the
- corresponding character in str, beginning at position pos,
- is 0. Otherwise, the element has the value one.
- </pre>
- <pre>23.3.5.2:
- -33- Effects: Constructs a string object of the appropriate
- type and initializes it to a string of length N characters.
- Each character is determined by the value of its
- corresponding bit position in *this. Character position N
- ?- 1 corresponds to bit position zero. Subsequent decreasing
- character positions correspond to increasing bit positions.
- Bit value zero becomes the character 0, bit value one becomes
- the character 1.
- </pre>
- <p>
-Also note the typo in 23.3.5.1, p6: the object under construction
-is a bitset, not a string.
- </p>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-We note that <tt>bitset</tt> has been moved from section 23 to section 20, by
-another issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>) previously resolved at this meeting.
-</p>
-<p>
-Disposition: move to ready.
-</p>
-<p>
-We request that Howard submit a separate issue regarding the three to_string overloads.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the constructor's function declaration immediately before
-23.3.5.1 [bitset.cons] p3 to:</p>
-<pre> template &lt;class charT, class traits, class Allocator&gt;
- explicit
- bitset(const basic_string&lt;charT, traits, Allocator&gt;&amp; str,
- typename basic_string&lt;charT, traits, Allocator&gt;::size_type pos = 0,
- typename basic_string&lt;charT, traits, Allocator&gt;::size_type n =
- basic_string&lt;charT, traits, Allocator&gt;::npos,
- charT zero = charT('0'), charT one = charT('1'))
-</pre>
-<p>Change the first two sentences of 23.3.5.1 [bitset.cons] p6 to: "An
-element of the constructed string has value 0 if the corresponding
-character in <i>str</i>, beginning at position <i>pos</i>,
-is <i>zero</i>. Otherwise, the element has the value 1.</p>
-
-<p>Change the text of the second sentence in 23.3.5.1, p5 to read:
- "The function then throws invalid_argument if any of the rlen
- characters in str beginning at position pos is other than <i>zero</i>
- or <i>one</i>. The function uses traits::eq() to compare the character
- values."
-</p>
-
-<p>Change the declaration of the <tt>to_string</tt> member function
- immediately before 23.3.5.2 [bitset.members] p33 to:</p>
-<pre> template &lt;class charT, class traits, class Allocator&gt;
- basic_string&lt;charT, traits, Allocator&gt;
- to_string(charT zero = charT('0'), charT one = charT('1')) const;
-</pre>
-<p>Change the last sentence of 23.3.5.2 [bitset.members] p33 to: "Bit
- value 0 becomes the character <tt><i>zero</i></tt>, bit value 1 becomes the
- character <tt><i>one</i></tt>.</p>
-<p>Change 23.3.5.3 [bitset.operators] p8 to:</p>
-<p><b>Returns</b>:</p>
-<pre> os &lt;&lt; x.template to_string&lt;charT,traits,allocator&lt;charT&gt; &gt;(
- use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('0'),
- use_facet&lt;ctype&lt;charT&gt; &gt;(<i>os</i>.getloc()).widen('1'));
-</pre>
-
-
-<p><b>Rationale:</b></p>
-<p>There is a real problem here: we need the character values of '0'
- and '1', and we have no way to get them since strings don't have
- imbued locales. In principle the "right" solution would be to
- provide an extra object, either a ctype facet or a full locale,
- which would be used to widen '0' and '1'. However, there was some
- discomfort about using such a heavyweight mechanism. The proposed
- resolution allows those users who care about this issue to get it
- right.</p>
-<p>We fix the inserter to use the new arguments. Note that we already
- fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>.</p>
-
-
-
-<p><i>[
-post Bellevue:
-]</i></p>
-
-
-<blockquote>
-We are happy with the resolution as proposed, and we move this to Ready.
-</blockquote>
-
-<p><i>[
-Howard adds:
-]</i></p>
-
-
-<blockquote>
-The proposed wording neglects the 3 newer to_string overloads.
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="397"></a>397. ostream::sentry dtor throws exceptions</h3>
-<p><b>Section:</b> 27.6.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-17.4.4.8, p3 prohibits library dtors from throwing exceptions.
- </p>
- <p>
-27.6.2.3, p4 says this about the ostream::sentry dtor:
- </p>
- <pre> -4- If ((os.flags() &amp; ios_base::unitbuf) &amp;&amp; !uncaught_exception())
- is true, calls os.flush().
- </pre>
- <p>
-27.6.2.6, p7 that describes ostream::flush() says:
- </p>
- <pre> -7- If rdbuf() is not a null pointer, calls rdbuf()-&gt;pubsync().
- If that function returns ?-1 calls setstate(badbit) (which
- may throw ios_base::failure (27.4.4.3)).
- </pre>
- <p>
-That seems like a defect, since both pubsync() and setstate() can
-throw an exception.
- </p>
-<p><i>[
-The contradiction is real. Clause 17 says destructors may never
-throw exceptions, and clause 27 specifies a destructor that does
-throw. In principle we might change either one. We're leaning
-toward changing clause 17: putting in an "unless otherwise specified"
-clause, and then putting in a footnote saying the sentry destructor
-is the only one that can throw. PJP suggests specifying that
-sentry::~sentry() should internally catch any exceptions it might cause.
-]</i></p>
-
-
-<p><i>[
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="398"></a>398. effects of end-of-file on unformatted input functions</h3>
-<p><b>Section:</b> 27.6.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-While reviewing unformatted input member functions of istream
-for their behavior when they encounter end-of-file during input
-I found that the requirements vary, sometimes unexpectedly, and
-in more than one case even contradict established practice (GNU
-libstdc++ 3.2, IBM VAC++ 6.0, STLPort 4.5, SunPro 5.3, HP aCC
-5.38, Rogue Wave libstd 3.1, and Classic Iostreams).
- </p>
- <p>
-The following unformatted input member functions set eofbit if they
-encounter an end-of-file (this is the expected behavior, and also
-the behavior of all major implementations):
- </p>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- get (char_type*, streamsize, char_type);
- </pre>
- <p>
- Also sets failbit if it fails to extract any characters.
- </p>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- get (char_type*, streamsize);
- </pre>
- <p>
- Also sets failbit if it fails to extract any characters.
- </p>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- getline (char_type*, streamsize, char_type);
- </pre>
- <p>
- Also sets failbit if it fails to extract any characters.
- </p>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- getline (char_type*, streamsize);
- </pre>
- <p>
- Also sets failbit if it fails to extract any characters.
- </p>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- ignore (int, int_type);
- </pre>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- read (char_type*, streamsize);
- </pre>
- <p>
- Also sets failbit if it encounters end-of-file.
- </p>
- <pre> streamsize readsome (char_type*, streamsize);
- </pre>
-
- <p>
-The following unformated input member functions set failbit but
-not eofbit if they encounter an end-of-file (I find this odd
-since the functions make it impossible to distinguish a general
-failure from a failure due to end-of-file; the requirement is
-also in conflict with all major implementation which set both
-eofbit and failbit):
- </p>
- <pre> int_type get();
- </pre>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- get (char_type&amp;);
- </pre>
- <p>
-These functions only set failbit of they extract no characters,
-otherwise they don't set any bits, even on failure (I find this
-inconsistency quite unexpected; the requirement is also in
-conflict with all major implementations which set eofbit
-whenever they encounter end-of-file):
- </p>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- get (basic_streambuf&lt;charT, traits&gt;&amp;, char_type);
- </pre>
- <pre> basic_istream&lt;charT, traits&gt;&amp;
- get (basic_streambuf&lt;charT, traits&gt;&amp;);
- </pre>
- <p>
-This function sets no bits (all implementations except for
-STLport and Classic Iostreams set eofbit when they encounter
-end-of-file):
- </p>
- <pre> int_type peek ();
- </pre>
-<p>Informally, what we want is a global statement of intent saying
- that eofbit gets set if we trip across EOF, and then we can take
- away the specific wording for individual functions. A full review
- is necessary. The wording currently in the standard is a mishmash,
- and changing it on an individual basis wouldn't make things better.
- Dietmar will do this work.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-<hr>
-<h3><a name="408"></a>408. Is vector&lt;reverse_iterator&lt;char*&gt; &gt; forbidden?</h3>
-<p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I've been discussing iterator semantics with Dave Abrahams, and a
-surprise has popped up. I don't think this has been discussed before.
-</p>
-
-<p>
-24.1 [iterator.requirements] says that the only operation that can be performed on "singular"
-iterator values is to assign a non-singular value to them. (It
-doesn't say they can be destroyed, and that's probably a defect.)
-Some implementations have taken this to imply that there is no need
-to initialize the data member of a reverse_iterator&lt;&gt; in the default
-constructor. As a result, code like
-</p>
-<blockquote><pre> std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt; v(7);
- v.reserve(1000);
-</pre></blockquote>
-<p>
-invokes undefined behavior, because it must default-initialize the
-vector elements, and then copy them to other storage. Of course many
-other vector operations on these adapters are also left undefined,
-and which those are is not reliably deducible from the standard.
-</p>
-
-<p>
-I don't think that 24.1 was meant to make standard-library iterator
-types unsafe. Rather, it was meant to restrict what operations may
-be performed by functions which take general user- and standard
-iterators as arguments, so that raw pointers would qualify as
-iterators. However, this is not clear in the text, others have come
-to the opposite conclusion.
-</p>
-
-<p>
-One question is whether the standard iterator adaptors have defined
-copy semantics. Another is whether they have defined destructor
-semantics: is
-</p>
-<blockquote><pre> { std::vector&lt;std::reverse_iterator&lt;char*&gt; &gt; v(7); }
-</pre></blockquote>
-<p>
-undefined too?
-</p>
-
-<p>
-Note this is not a question of whether algorithms are allowed to
-rely on copy semantics for arbitrary iterators, just whether the
-types we actually supply support those operations. I believe the
-resolution must be expressed in terms of the semantics of the
-adapter's argument type. It should make clear that, e.g., the
-reverse_iterator&lt;T&gt; constructor is actually required to execute
-T(), and so copying is defined if the result of T() is copyable.
-</p>
-
-<p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, which defines reverse_iterator's default
-constructor more precisely, has some relevance to this issue.
-However, it is not the whole story.
-</p>
-
-<p>
-The issue was whether
-</p>
-<blockquote><pre> reverse_iterator() { }
-</pre></blockquote>
-<p>
-is allowed, vs.
-</p>
-<blockquote><pre> reverse_iterator() : current() { }
-</pre></blockquote>
-
-<p>
-The difference is when T is char*, where the first leaves the member
-uninitialized, and possibly equal to an existing pointer value, or
-(on some targets) may result in a hardware trap when copied.
-</p>
-
-<p>
-8.5 paragraph 5 seems to make clear that the second is required to
-satisfy DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, at least for non-class Iterator argument
-types.
-</p>
-
-<p>
-But that only takes care of reverse_iterator, and doesn't establish
-a policy for all iterators. (The reverse iterator adapter was just
-an example.) In particular, does my function
-</p>
-<blockquote><pre> template &lt;typename Iterator&gt;
- void f() { std::vector&lt;Iterator&gt; v(7); }
-</pre></blockquote>
-<p>
-evoke undefined behavior for some conforming iterator definitions?
-I think it does, now, because vector&lt;&gt; will destroy those singular
-iterator values, and that's explicitly disallowed.
-</p>
-
-<p>
-24.1 shouldn't give blanket permission to copy all singular iterators,
-because then pointers wouldn't qualify as iterators. However, it
-should allow copying of that subset of singular iterator values that
-are default-initialized, and it should explicitly allow destroying any
-iterator value, singular or not, default-initialized or not.
-</p>
-
-<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#407">407</a></p>
-<p><i>[
-We don't want to require all singular iterators to be copyable,
-because that is not the case for pointers. However, default
-construction may be a special case. Issue: is it really default
-construction we want to talk about, or is it something like value
-initialization? We need to check with core to see whether default
-constructed pointers are required to be copyable; if not, it would be
-wrong to impose so strict a requirement for iterators.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="417"></a>417. what does ctype::do_widen() return on failure</h3>
-<p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The Effects and Returns clauses of the do_widen() member function of
-the ctype facet fail to specify the behavior of the function on failure.
-That the function may not be able to simply cast the narrow character
-argument to the type of the result since doing so may yield the wrong value
-for some wchar_t encodings. Popular implementations of ctype&lt;wchar_t&gt; that
-use mbtowc() and UTF-8 as the native encoding (e.g., GNU glibc) will fail
-when the argument's MSB is set. There is no way for the the rest of locale
-and iostream to reliably detect this failure.
-</p>
-<p><i>[Kona: This is a real problem. Widening can fail. It's unclear
- what the solution should be. Returning WEOF works for the wchar_t
- specialization, but not in general. One option might be to add a
- default, like <i>narrow</i>. But that's an incompatible change.
- Using <i>traits::eof</i> might seem like a good idea, but facets
- don't have access to traits (a recurring problem). We could
- have <i>widen</i> throw an exception, but that's a scary option;
- existing library components aren't written with the assumption
- that <i>widen</i> can throw.]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-<hr>
-<h3><a name="418"></a>418. exceptions thrown during iostream cleanup</h3>
-<p><b>Section:</b> 27.4.2.1.6 [ios::Init] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The dtor of the ios_base::Init object is supposed to call flush() on the
-6 standard iostream objects cout, cerr, clog, wcout, wcerr, and wclog.
-This call may cause an exception to be thrown.
-</p>
-
-<p>
-17.4.4.8, p3 prohibits all library destructors from throwing exceptions.
-</p>
-
-<p>
-The question is: What should this dtor do if one or more of these calls
-to flush() ends up throwing an exception? This can happen quite easily
-if one of the facets installed in the locale imbued in the iostream
-object throws.
-</p>
-<p><i>[Kona: We probably can't do much better than what we've got, so
- the LWG is leaning toward NAD. At the point where the standard
- stream objects are being cleaned up, the usual error reporting
- mechanism are all unavailable. And exception from flush at this
- point will definitely cause problems. A quality implementation
- might reasonably swallow the exception, or call abort, or do
- something even more drastic.]</i></p>
-
-
-<p><i>[
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a> for related issues.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-<hr>
-<h3><a name="419"></a>419. istream extractors not setting failbit if eofbit is already set</h3>
-<p><b>Section:</b> 27.6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-27.6.1.1.3 [istream::sentry], p2 says that istream::sentry ctor prepares for input if is.good()
-is true. p4 then goes on to say that the ctor sets the sentry::ok_ member to
-true if the stream state is good after any preparation. 27.6.1.2.1 [istream.formatted.reqmts], p1 then
-says that a formatted input function endeavors to obtain the requested input
-if the sentry's operator bool() returns true.
-
-Given these requirements, no formatted extractor should ever set failbit if
-the initial stream rdstate() == eofbit. That is contrary to the behavior of
-all implementations I tested. The program below prints out
-
-eof = 1, fail = 0
-eof = 1, fail = 1
-
-on all of them.
- </p>
-<pre>
-#include &lt;sstream&gt;
-#include &lt;cstdio&gt;
-
-int main()
-{
- std::istringstream strm ("1");
-
- int i = 0;
-
- strm &gt;&gt; i;
-
- std::printf ("eof = %d, fail = %d\n",
- !!strm.eof (), !!strm.fail ());
-
- strm &gt;&gt; i;
-
- std::printf ("eof = %d, fail = %d\n",
- !!strm.eof (), !!strm.fail ());
-}
-
-</pre>
- <p>
-<br>
-
-Comments from Jerry Schwarz (c++std-lib-11373):
-<br>
-
-Jerry Schwarz wrote:
-<br>
-
-I don't know where (if anywhere) it says it in the standard, but the
-formatted extractors are supposed to set failbit if they don't extract
-any characters. If they didn't then simple loops like
-<br>
-
-while (cin &gt;&gt; x);
-<br>
-
-would loop forever.
-<br>
-
-Further comments from Martin Sebor:
-<br>
-
-The question is which part of the extraction should prevent this from happening
-by setting failbit when eofbit is already set. It could either be the sentry
-object or the extractor. It seems that most implementations have chosen to
-set failbit in the sentry [...] so that's the text that will need to be
-corrected.
-
- </p>
-<p>
-Pre Berlin: This issue is related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>. If the sentry
-sets <tt>failbit</tt> when it finds <tt>eofbit</tt> already set, then
-you can never seek away from the end of stream.
-</p>
-<p>Kona: Possibly NAD. If eofbit is set then good() will return false. We
- then set <i>ok</i> to false. We believe that the sentry's
- constructor should always set failbit when <i>ok</i> is false, and
- we also think the standard already says that. Possibly it could be
- clearer.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 27.6.1.1.3 [istream::sentry], p2 to:
-</p>
-
-<blockquote>
-<pre>explicit sentry(basic_istream&lt;charT,traits&gt;&amp; <i>is</i> , bool <i>noskipws</i> = false);</pre>
-<p>
--2- <i>Effects:</i> If <tt>is.good()</tt> is <del><tt>true</tt></del>
-<ins><tt>false</tt></ins>, <ins>calls <tt>is.setstate(failbit)</tt>.
-Otherwise</ins> prepares for formatted or unformatted input. ...
-</p>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="421"></a>421. is basic_streambuf copy-constructible?</h3>
-<p><b>Section:</b> 27.5.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.cons">issues</a> in [streambuf.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The reflector thread starting with c++std-lib-11346 notes that the class
-template basic_streambuf, along with basic_stringbuf and basic_filebuf,
-is copy-constructible but that the semantics of the copy constructors
-are not defined anywhere. Further, different implementations behave
-differently in this respect: some prevent copy construction of objects
-of these types by declaring their copy ctors and assignment operators
-private, others exhibit undefined behavior, while others still give
-these operations well-defined semantics.
-</p>
-
-<p>
-Note that this problem doesn't seem to be isolated to just the three
-types mentioned above. A number of other types in the library section
-of the standard provide a compiler-generated copy ctor and assignment
-operator yet fail to specify their semantics. It's believed that the
-only types for which this is actually a problem (i.e. types where the
-compiler-generated default may be inappropriate and may not have been
-intended) are locale facets. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#439">439</a>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-27.5.2 [lib.streambuf]: Add into the synopsis, public section, just above the destructor declaration:
-</p>
-
-<blockquote>
-<pre>basic_streambuf(const basic_streambuf&amp; sb);
-basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
-</pre>
-</blockquote>
-
-<p>Insert after 27.5.2.1, paragraph 2:</p>
-<blockquote>
-<pre>basic_streambuf(const basic_streambuf&amp; sb);
-</pre>
-
-<p>Constructs a copy of sb.</p>
-<p>Postcondtions:</p>
-<pre> eback() == sb.eback()
- gptr() == sb.gptr()
- egptr() == sb.egptr()
- pbase() == sb.pbase()
- pptr() == sb.pptr()
- epptr() == sb.epptr()
- getloc() == sb.getloc()
-</pre>
-
-<pre>basic_streambuf&amp; operator=(const basic_streambuf&amp; sb);
-</pre>
-
-<p>Assigns the data members of sb to this.</p>
-
-<p>Postcondtions:</p>
-<pre> eback() == sb.eback()
- gptr() == sb.gptr()
- egptr() == sb.egptr()
- pbase() == sb.pbase()
- pptr() == sb.pptr()
- epptr() == sb.epptr()
- getloc() == sb.getloc()
-</pre>
-
-<p>Returns: *this.</p>
-</blockquote>
-
-<p>27.7.1 [lib.stringbuf]:</p>
-
-<p><b>Option A:</b></p>
-
-<blockquote>
-<p>Insert into the basic_stringbuf synopsis in the private section:</p>
-
-<pre>basic_stringbuf(const basic_stringbuf&amp;); // not defined
-basic_stringbuf&amp; operator=(const basic_stringbuf&amp;); // not defined
-</pre>
-</blockquote>
-
-<p><b>Option B:</b></p>
-
-<blockquote>
-<p>Insert into the basic_stringbuf synopsis in the public section:</p>
-
-<pre>basic_stringbuf(const basic_stringbuf&amp; sb);
-basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);
-</pre>
-
-<p>27.7.1.1, insert after paragraph 4:</p>
-
-<pre>basic_stringbuf(const basic_stringbuf&amp; sb);</pre>
-
-<p>
-Constructs an independent copy of sb as if with sb.str(), and with the openmode that sb was constructed with.
-</p>
-
-<p>Postcondtions: </p>
-<pre> str() == sb.str()
- gptr() - eback() == sb.gptr() - sb.eback()
- egptr() - eback() == sb.egptr() - sb.eback()
- pptr() - pbase() == sb.pptr() - sb.pbase()
- getloc() == sb.getloc()
-</pre>
-
-<p>
-Note: The only requirement on epptr() is that it point beyond the
-initialized range if an output sequence exists. There is no requirement
-that epptr() - pbase() == sb.epptr() - sb.pbase().
-</p>
-
-<pre>basic_stringbuf&amp; operator=(const basic_stringbuf&amp; sb);</pre>
-<p>After assignment the basic_stringbuf has the same state as if it
-were initially copy constructed from sb, except that the
-basic_stringbuf is allowed to retain any excess capacity it might have,
-which may in turn effect the value of epptr().
-</p>
-</blockquote>
-
-<p>27.8.1.1 [lib.filebuf]</p>
-
-<p>Insert at the bottom of the basic_filebuf synopsis:</p>
-
-<blockquote>
-<pre>private:
- basic_filebuf(const basic_filebuf&amp;); // not defined
- basic_filebuf&amp; operator=(const basic_filebuf&amp;); // not defined
-</pre>
-</blockquote>
-<p><i>[Kona: this is an issue for basic_streambuf itself and for its
- derived classes. We are leaning toward allowing basic_streambuf to
- be copyable, and specifying its precise semantics. (Probably the
- obvious: copying the buffer pointers.) We are less sure whether
- the streambuf derived classes should be copyable. Howard will
- write up a proposal.]</i></p>
-
-
-<p><i>[Sydney: Dietmar presented a new argument against basic_streambuf
- being copyable: it can lead to an encapsulation violation. Filebuf
- inherits from streambuf. Now suppose you inhert a my_hijacking_buf
- from streambuf. You can copy the streambuf portion of a filebuf to a
- my_hijacking_buf, giving you access to the pointers into the
- filebuf's internal buffer. Perhaps not a very strong argument, but
- it was strong enough to make people nervous. There was weak
- preference for having streambuf not be copyable. There was weak
- preference for having stringbuf not be copyable even if streambuf
- is. Move this issue to open for now.
-]</i></p>
-
-
-<p><i>[
-2007-01-12, Howard:
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1862.html#27.5.2%20-%20Class%20template%20basic_streambuf%3CcharT,traits%3E">Rvalue Reference Recommendations for Chapter 27</a>
-recommends protected copy constructor and assignment for <tt>basic_streambuf</tt> with the same semantics
-as would be generated by the compiler. These members aid in derived classes implementing move semantics.
-A protected copy constructor and copy assignment operator do not expose encapsulation more so than it is
-today as each data member of a <tt>basic_streambuf</tt> is already both readable and writable by derived
-classes via various get/set protected member functions (<tt>eback()</tt>, <tt>setp()</tt>, etc.). Rather
-a protected copy constructor and copy assignment operator simply make the job of derived classes implementing
-move semantics less tedious and error prone.
-]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-27.5.2 [lib.streambuf]: The proposed basic_streambuf copy constructor
-and assignment operator are the same as currently implied by the lack
-of declarations: public and simply copies the data members. This
-resolution is not a change but a clarification of the current
-standard.
-</p>
-
-<p>
-27.7.1 [lib.stringbuf]: There are two reasonable options: A) Make
-basic_stringbuf not copyable. This is likely the status-quo of
-current implementations. B) Reasonable copy semantics of
-basic_stringbuf can be defined and implemented. A copyable
-basic_streambuf is arguably more useful than a non-copyable one. This
-should be considered as new functionality and not the fixing of a
-defect. If option B is chosen, ramifications from issue 432 are taken
-into account.
-</p>
-
-<p>
-27.8.1.1 [lib.filebuf]: There are no reasonable copy semantics for
-basic_filebuf.
-</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="423"></a>423. effects of negative streamsize in iostreams</h3>
-<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-A third party test suite tries to exercise istream::ignore(N) with
-a negative value of N and expects that the implementation will treat
-N as if it were 0. Our implementation asserts that (N &gt;= 0) holds and
-aborts the test.
-</p>
-
-<p>
-I can't find anything in section 27 that prohibits such values but I don't
-see what the effects of such calls should be, either (this applies to
-a number of unformatted input functions as well as some member functions
-of the basic_streambuf template).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-I propose that we add to each function in clause 27 that takes an argument,
-say N, of type streamsize a Requires clause saying that "N &gt;= 0." The intent
-is to allow negative streamsize values in calls to precision() and width()
-but disallow it in calls to streambuf::sgetn(), istream::ignore(), or
-ostream::write().
-</p>
-
-<p><i>[Kona: The LWG agreed that this is probably what we want. However, we
- need a review to find all places where functions in clause 27 take
- arguments of type streamsize that shouldn't be allowed to go
- negative. Martin will do that review.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="427"></a>427. stage 2 and rationale of DR 221</h3>
-<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The requirements specified in Stage 2 and reiterated in the rationale
-of DR 221 (and echoed again in DR 303) specify that num_get&lt;charT&gt;::
-do_get() compares characters on the stream against the widened elements
-of "012...abc...ABCX+-"
-</p>
-
-<p>
-An implementation is required to allow programs to instantiate the num_get
-template on any charT that satisfies the requirements on a user-defined
-character type. These requirements do not include the ability of the
-character type to be equality comparable (the char_traits template must
-be used to perform tests for equality). Hence, the num_get template cannot
-be implemented to support any arbitrary character type. The num_get template
-must either make the assumption that the character type is equality-comparable
-(as some popular implementations do), or it may use char_traits&lt;charT&gt; to do
-the comparisons (some other popular implementations do that). This diversity
-of approaches makes it difficult to write portable programs that attempt to
-instantiate the num_get template on user-defined types.
-</p>
-
-<p><i>[Kona: the heart of the problem is that we're theoretically
- supposed to use traits classes for all fundamental character
- operations like assignment and comparison, but facets don't have
- traits parameters. This is a fundamental design flaw and it
- appears all over the place, not just in this one place. It's not
- clear what the correct solution is, but a thorough review of facets
- and traits is in order. The LWG considered and rejected the
- possibility of changing numeric facets to use narrowing instead of
- widening. This may be a good idea for other reasons (see issue
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#459">459</a>), but it doesn't solve the problem raised by this
- issue. Whether we use widen or narrow the <tt>num_get</tt> facet
- still has no idea which traits class the user wants to use for
- the comparison, because only streams, not facets, are passed traits
- classes. The standard does not require that two different
- traits classes with the same <tt>char_type</tt> must necessarily
- have the same behavior.]</i></p>
-
-
-<p>Informally, one possibility: require that some of the basic
-character operations, such as <tt>eq</tt>, <tt>lt</tt>,
-and <tt>assign</tt>, must behave the same way for all traits classes
-with the same <tt>char_type</tt>. If we accept that limitation on
-traits classes, then the facet could reasonably be required to
-use <tt>char_traits&lt;charT&gt;</tt>.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-<hr>
-<h3><a name="430"></a>430. valarray subset operations</h3>
-<p><b>Section:</b> 26.5.2.4 [valarray.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The standard fails to specify the behavior of valarray::operator[](slice)
-and other valarray subset operations when they are passed an "invalid"
-slice object, i.e., either a slice that doesn't make sense at all (e.g.,
-slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
-object (e.g., slice (2, 1, 1) for a valarray of size 1).
-</p>
-<p><i>[Kona: the LWG believes that invalid slices should invoke
- undefined behavior. Valarrays are supposed to be designed for high
- performance, so we don't want to require specific checking. We
- need wording to express this decision.]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Please note that the standard also fails to specify the behavior of
-slice_array and gslice_array in the valid case. Bill Plauger will
-endeavor to provide revised wording for slice_array and gslice_array.
-</blockquote>
-
-<p><i>[
-post-Bellevue: Bill provided wording.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Insert after 26.5.2.4 [valarray.sub], paragraph 1:
-</p>
-
-<blockquote>
-<p>
-The member operator is overloaded to provide several ways to select
-sequences
-of elements from among those controlled by <tt>*this</tt>. The first group of five
-member operators work in conjunction with various overloads of <tt>operator=</tt>
-(and other assigning operators) to allow selective replacement (slicing) of
-the controlled sequence. The selected elements must exist.
-</p>
-<p>
-The first member operator selects element off. For example:
-</p>
-
-<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
-v0[3] = 'A';
-// v0 == valarray&lt;char&gt;("abcAefghijklmnop", 16)
-</pre></blockquote>
-
-<p>
-The second member operator selects those elements of the controlled sequence
-designated by <tt>slicearr</tt>. For example:
-</p>
-
-<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
-valarray&lt;char&gt; v1("ABCDE", 5);
-v0[slice(2, 5, 3)] = v1;
-// v0 == valarray&lt;char&gt;("abAdeBghCjkDmnEp", 16)
-</pre></blockquote>
-
-<p>
-The third member operator selects those elements of the controlled sequence
-designated by <tt>gslicearr</tt>. For example:
-</p>
-
-<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
-valarray&lt;char&gt; v1("ABCDEF", 6);
-const size_t lv[] = {2, 3};
-const size_t dv[] = {7, 2};
-const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2);
-v0[gslice(3, len, str)] = v1;
-// v0 == valarray&lt;char&gt;("abcAeBgCijDlEnFp", 16)
-</pre></blockquote>
-
-<p>
-The fourth member operator selects those elements of the controlled sequence
-designated by <tt>boolarr</tt>. For example:
-</p>
-
-<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
-valarray&lt;char&gt; v1("ABC", 3);
-const bool vb[] = {false, false, true, true, false, true};
-v0[valarray&lt;bool&gt;(vb, 6)] = v1;
-// v0 == valarray&lt;char&gt;("abABeCghijklmnop", 16)
-</pre></blockquote>
-
-<p>
-The fifth member operator selects those elements of the controlled sequence
-designated by indarr. For example:
-</p>
-
-<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
-valarray&lt;char&gt; v1("ABCDE", 5);
-const size_t vi[] = {7, 5, 2, 3, 8};
-v0[valarray&lt;size_t&gt;(vi, 5)] = v1;
-// v0 == valarray&lt;char&gt;("abCDeBgAEjklmnop", 16)
-</pre></blockquote>
-
-<p>
-The second group of five member operators each construct an object that
-represents the value(s) selected. The selected elements must exist.
-</p>
-
-<p>
-The sixth member operator returns the value of element off. For example:
-</p>
-
-<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
-// v0[3] returns 'd'
-</pre></blockquote>
-
-<p>
-The seventh member operator returns an object of class <tt>valarray&lt;Ty&gt;</tt>
-containing those elements of the controlled sequence designated by <tt>slicearr</tt>.
-For example:
-</p>
-
-<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
-// v0[slice(2, 5, 3)] returns valarray&lt;char&gt;("cfilo", 5)
-</pre></blockquote>
-
-<p>
-The eighth member operator selects those elements of the controlled sequence
-designated by <tt>gslicearr</tt>. For example:
-</p>
-
-<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
-const size_t lv[] = {2, 3};
-const size_t dv[] = {7, 2};
-const valarray&lt;size_t&gt; len(lv, 2), str(dv, 2);
-// v0[gslice(3, len, str)] returns
-// &nbsp;&nbsp;&nbsp;valarray&lt;char&gt;("dfhkmo", 6)
-</pre></blockquote>
-
-<p>
-The ninth member operator selects those elements of the controlled sequence
-designated by <tt>boolarr</tt>. For example:
-</p>
-
-<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
-const bool vb[] = {false, false, true, true, false, true};
-// v0[valarray&lt;bool&gt;(vb, 6)] returns
-// &nbsp;&nbsp;&nbsp;valarray&lt;char&gt;("cdf", 3)
-</pre></blockquote>
-
-<p>
-The last member operator selects those elements of the controlled sequence
-designated by <tt>indarr</tt>. For example:
-</p>
-
-<blockquote><pre>valarray&lt;char&gt; v0("abcdefghijklmnop", 16);
-const size_t vi[] = {7, 5, 2, 3, 8};
-// v0[valarray&lt;size_t&gt;(vi, 5)] returns
-// valarray&lt;char&gt;("hfcdi", 5)
-</pre></blockquote>
-
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="431"></a>431. Swapping containers with unequal allocators</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-09-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Clause 20.1.2 [allocator.requirements] paragraph 4 says that implementations
- are permitted to supply containers that are unable to cope with
- allocator instances and that container implementations may assume
- that all instances of an allocator type compare equal. We gave
- implementers this latitude as a temporary hack, and eventually we
- want to get rid of it. What happens when we're dealing with
- allocators that <i>don't</i> compare equal?
-</p>
-
-<p>In particular: suppose that <tt>v1</tt> and <tt>v2</tt> are both
- objects of type <tt>vector&lt;int, my_alloc&gt;</tt> and that
- <tt>v1.get_allocator() != v2.get_allocator()</tt>. What happens if
- we write <tt>v1.swap(v2)</tt>? Informally, three possibilities:</p>
-
-<p>1. This operation is illegal. Perhaps we could say that an
- implementation is required to check and to throw an exception, or
- perhaps we could say it's undefined behavior.</p>
-<p>2. The operation performs a slow swap (i.e. using three
- invocations of <tt>operator=</tt>, leaving each allocator with its
- original container. This would be an O(N) operation.</p>
-<p>3. The operation swaps both the vectors' contents and their
- allocators. This would be an O(1) operation. That is:</p>
- <blockquote>
- <pre> my_alloc a1(...);
- my_alloc a2(...);
- assert(a1 != a2);
-
- vector&lt;int, my_alloc&gt; v1(a1);
- vector&lt;int, my_alloc&gt; v2(a2);
- assert(a1 == v1.get_allocator());
- assert(a2 == v2.get_allocator());
-
- v1.swap(v2);
- assert(a1 == v2.get_allocator());
- assert(a2 == v1.get_allocator());
- </pre>
- </blockquote>
-
-<p><i>[Kona: This is part of a general problem. We need a paper
- saying how to deal with unequal allocators in general.]</i></p>
-
-
-<p><i>[pre-Sydney: Howard argues for option 3 in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html">N1599</a>.
-]</i></p>
-
-
-<p><i>[
-2007-01-12, Howard: This issue will now tend to come up more often with move constructors
-and move assignment operators. For containers, these members transfer resources (i.e.
-the allocated memory) just like swap.
-]</i></p>
-
-
-<p><i>[
-Batavia: There is agreement to overload the container <tt>swap</tt> on the allocator's Swappable
-requirement using concepts. If the allocator supports Swappable, then container's swap will
-swap allocators, else it will perform a "slow swap" using copy construction and copy assignment.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="446"></a>446. Iterator equality between different containers</h3>
-<p><b>Section:</b> 24.1 [iterator.requirements], 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Andy Koenig <b>Date:</b> 2003-12-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-What requirements does the standard place on equality comparisons between
-iterators that refer to elements of different containers. For example, if
-v1 and v2 are empty vectors, is v1.end() == v2.end() allowed to yield true?
-Is it allowed to throw an exception?
-</p>
-
-<p>
-The standard appears to be silent on both questions.
-</p>
-<p><i>[Sydney: The intention is that comparing two iterators from
-different containers is undefined, but it's not clear if we say that,
-or even whether it's something we should be saying in clause 23 or in
-clause 24. Intuitively we might want to say that equality is defined
-only if one iterator is reachable from another, but figuring out how
-to say it in any sensible way is a bit tricky: reachability is defined
-in terms of equality, so we can't also define equality in terms of
-reachability.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="454"></a>454. basic_filebuf::open should accept wchar_t names</h3>
-<p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a></p>
-<p><b>Discussion:</b></p>
-<pre> basic_filebuf *basic_filebuf::open(const char *, ios_base::open_mode);
-</pre>
-
-<p>should be supplemented with the overload:</p>
-
-<pre> basic_filebuf *basic_filebuf::open(const wchar_t *, ios_base::open_mode);
-</pre>
-
-<p>
-Depending on the operating system, one of these forms is fundamental and
-the other requires an implementation-defined mapping to determine the
-actual filename.
-</p>
-
-<p><i>[Sydney: Yes, we want to allow wchar_t filenames. Bill will
- provide wording.]</i></p>
-
-
-<p><i>[
-In Toronto we noted that this is issue 5 from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1569.htm">N1569</a>.
-]</i></p>
-
-<p>
-How does this interact with the newly-defined character types, and how
-do we avoid interface explosion considering <tt>std::string</tt> overloads that
-were added? Propose another solution that is different than the
-suggestion proposed by PJP.
-</p>
-<p>
-Suggestion is to make a member template function for <tt>basic_string</tt> (for
-<tt>char</tt>, <tt>wchar_t</tt>, <tt>u16char</tt>, <tt>u32char</tt> instantiations), and then just keep a
-<tt>const char*</tt> member.
-</p>
-<p>
-Goal is to do implicit conversion between character string literals to
-appropriate <tt>basic_string</tt> type. Not quite sure if this is possible.
-</p>
-<p>
-Implementors are free to add specific overloads for non-char character
-types.
-</p>
-
-<p><i>[
-Martin adds pre-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-Please see <a href="http://wiki.dinkumware.com/twiki/pub/Wg21sophiaAntipolis/LibraryWorkingGroup/issue-454.html">issue 454: problems and solutions</a>.
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-Beman is concerned that making these changes to <tt>basic_filebuf</tt> is not
-usefully changed unless <tt>fstream</tt> is also changed; this also only handles
-<tt>wchar_t</tt> and not other character types.
-</p>
-<p>
-The TR2 filesystem library is a more complete solution, but is not available soon.
-</p>
-</blockquote>
-
-<p><i>[
-Martin adds: please reference
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2683.html">N2683</a> for
-problems and solutions.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Change from:</p>
-<blockquote>
-<pre>basic_filebuf&lt;charT,traits&gt;* open(
- const char* s,
- ios_base::openmode mode );
-</pre>
-
-<p>
-Effects: If is_open() != false, returns a null pointer.
-Otherwise, initializes the filebuf as required. It then
-opens a file, if possible, whose name is the NTBS s ("as if"
-by calling std::fopen(s,modstr)).</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-<pre>basic_filebuf&lt;charT,traits&gt;* open(
- const char* s,
- ios_base::openmode mode );
-
-basic_filebuf&lt;charT,traits&gt;* open(
- const wchar_t* ws,
- ios_base::openmode mode );
-</pre>
-
-<p>
-Effects: If is_open() != false, returns a null pointer.
-Otherwise, initializes the filebuf as required. It then
-opens a file, if possible, whose name is the NTBS s ("as if"
-by calling std::fopen(s,modstr)).
-For the second signature, the NTBS s is determined from the
-WCBS ws in an implementation-defined manner.
-</p>
-
-<p>
-(NOTE: For a system that "naturally" represents a filename
-as a WCBS, the NTBS s in the first signature may instead
-be mapped to a WCBS; if so, it follows the same mapping
-rules as the first argument to open.)
-</p>
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Slightly controversial, but by a 7-1 straw poll the LWG agreed to move
-this to Ready. The controversy was because the mapping between wide
-names and files in a filesystem is implementation defined. The
-counterargument, which most but not all LWG members accepted, is that
-the mapping between narrow files names and files is also
-implemenation defined.</p>
-
-<p><i>[Lillehammer: Moved back to "open" status, at Beman's urging.
-(1) Why just basic_filebuf, instead of also basic_fstream (and
-possibly other things too). (2) Why not also constructors that take
-std::basic_string? (3) We might want to wait until we see Beman's
-filesystem library; we might decide that it obviates this.]</i></p>
-
-
-<p><i>[
-post Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Move again to Ready.
-</p>
-<p>
-There is a timing issue here. Since the filesystem library will not be
-in C++0x, this should be brought forward. This solution would remain
-valid in the context of the proposed filesystem.
-</p>
-<p>
-This issue has been kicking around for a while, and the wchar_t addition
-alone would help many users. Thus, we suggest putting this on the
-reflector list with an invitation for someone to produce proposed
-wording that covers basic_fstream. In the meantime, we suggest that the
-proposed wording be adopted as-is.
-</p>
-<p>
-If more of the Lillehammer questions come back, they should be
-introduced as separate issues.
-</p>
-</blockquote>
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="458"></a>458. 24.1.5 contains unintented limitation for operator-</h3>
-<p><b>Section:</b> 24.1.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-02-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 24.1.5 [lib.random.access.iterators], table 76 the operational
-semantics for the expression "r -= n" are defined as "return r += -n".
-This means, that the expression -n must be valid, which is not the case
-for unsigned types.
-</p>
-
-<p><i>[
-Sydney: Possibly not a real problem, since difference type is required
-to be a signed integer type. However, the wording in the standard may
-be less clear than we would like.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-To remove this limitation, I suggest to change the
-operational semantics for this column to:
-</p>
-<blockquote><pre> { Distance m = n;
- if (m &gt;= 0)
- while (m--) --r;
- else
- while (m++) ++r;
- return r; }
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="459"></a>459. Requirement for widening in stage 2 is overspecification</h3>
-<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-03-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>When parsing strings of wide-character digits, the standard
- requires the library to widen narrow-character "atoms" and compare
- the widened atoms against the characters that are being parsed.
- Simply narrowing the wide characters would be far simpler, and
- probably more efficient. The two choices are equivalent except in
- convoluted test cases, and many implementations already ignore the
- standard and use narrow instead of widen.</p>
-
-<p>
-First, I disagree that using narrow() instead of widen() would
-necessarily have unfortunate performance implications. A possible
-implementation of narrow() that allows num_get to be implemented
-in a much simpler and arguably comparably efficient way as calling
-widen() allows, i.e. without making a virtual call to do_narrow every
-time, is as follows:
-</p>
-
-<pre> inline char ctype&lt;wchar_t&gt;::narrow (wchar_t wc, char dflt) const
- {
- const unsigned wi = unsigned (wc);
-
- if (wi &gt; UCHAR_MAX)
- return typeid (*this) == typeid (ctype&lt;wchar_t&gt;) ?
- dflt : do_narrow (wc, dflt);
-
- if (narrow_ [wi] &lt; 0) {
- const char nc = do_narrow (wc, dflt);
- if (nc == dflt)
- return dflt;
- narrow_ [wi] = nc;
- }
-
- return char (narrow_ [wi]);
- }
-</pre>
-
-<p>
-Second, I don't think the change proposed in the issue (i.e., to use
-narrow() instead of widen() during Stage 2) would be at all
-drastic. Existing implementations with the exception of libstdc++
-currently already use narrow() so the impact of the change on programs
-would presumably be isolated to just a single implementation. Further,
-since narrow() is not required to translate alternate wide digit
-representations such as those mentioned in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>
-to
-their narrow equivalents (i.e., the portable source characters '0'
-through '9'), the change does not necessarily imply that these
-alternate digits would be treated as ordinary digits and accepted as
-part of numbers during parsing. In fact, the requirement in 22.2.1.1.2
-[locale.ctype.virtuals], p13 forbids narrow() to translate an alternate
-digit character, wc, to an ordinary digit in the basic source
-character set unless the expression
-(ctype&lt;charT&gt;::is(ctype_base::digit, wc) == true) holds. This in
-turn is prohibited by the C standard (7.25.2.1.5, 7.25.2.1.5, and
-5.2.1, respectively) for charT of either char or wchar_t.
-</p>
-
-<p><i>[Sydney: To a large extent this is a nonproblem. As long as
-you're only trafficking in char and wchar_t we're only dealing with a
-stable character set, so you don't really need either 'widen' or
-'narrow': can just use literals. Finally, it's not even clear whether
-widen-vs-narrow is the right question; arguably we should be using
-codecvt instead.]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change stage 2 so that implementations are permitted to use either
-technique to perform the comparison:</p>
-<ol>
- <li> call widen on the atoms and compare (either by using
- operator== or char_traits&lt;charT&gt;::eq) the input with
- the widened atoms, or</li>
- <li> call narrow on the input and compare the narrow input
- with the atoms</li>
- <li> do (1) or (2) only if charT is not char or wchar_t,
- respectively; i.e., avoid calling widen or narrow
- if it the source and destination types are the same</li>
-</ol>
-
-
-
-
-
-<hr>
-<h3><a name="463"></a>463. auto_ptr usability issues</h3>
-<p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Rani Sharoni <b>Date:</b> 2003-12-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-TC1 CWG DR #84 effectively made the template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;()
-member of auto_ptr (20.4.5.3/4) obsolete.
-</p>
-
-<p>
-The sole purpose of this obsolete conversion member is to enable copy
-initialization base from r-value derived (or any convertible types like
-cv-types) case:
-</p>
-<pre>#include &lt;memory&gt;
-using std::auto_ptr;
-
-struct B {};
-struct D : B {};
-
-auto_ptr&lt;D&gt; source();
-int sink(auto_ptr&lt;B&gt;);
-int x1 = sink( source() ); // #1 EDG - no suitable copy constructor
-</pre>
-
-<p>
-The excellent analysis of conversion operations that was given in the final
-auto_ptr proposal
-(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1128.pdf)
-explicitly specifies this case analysis (case 4). DR #84 makes the analysis
-wrong and actually comes to forbid the loophole that was exploited by the
-auto_ptr designers.
-</p>
-
-<p>
-I didn't encounter any compliant compiler (e.g. EDG, GCC, BCC and VC) that
-ever allowed this case. This is probably because it requires 3 user defined
-conversions and in fact current compilers conform to DR #84.
-</p>
-
-<p>
-I was surprised to discover that the obsolete conversion member actually has
-negative impact of the copy initialization base from l-value derived
-case:</p>
-<pre>auto_ptr&lt;D&gt; dp;
-int x2 = sink(dp); // #2 EDG - more than one user-defined conversion applies
-</pre>
-
-<p>
-I'm sure that the original intention was allowing this initialization using
-the template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;&amp; a) constructor (20.4.5.1/4) but
-since in this copy initialization it's merely user defined conversion (UDC)
-and the obsolete conversion member is UDC with the same rank (for the early
-overloading stage) there is an ambiguity between them.
-</p>
-
-<p>
-Removing the obsolete member will have impact on code that explicitly
-invokes it:
-</p>
-<pre>int y = sink(source().operator auto_ptr&lt;B&gt;());
-</pre>
-
-<p>
-IMHO no one ever wrote such awkward code and the reasonable workaround for
-#1 is:
-</p>
-<pre>int y = sink( auto_ptr&lt;B&gt;(source()) );
-</pre>
-
-<p>
-I was even more surprised to find out that after removing the obsolete
-conversion member the initialization was still ill-formed:
-int x3 = sink(dp); // #3 EDG - no suitable copy constructor
-</p>
-
-<p>
-This copy initialization semantically requires copy constructor which means
-that both template conversion constructor and the auto_ptr_ref conversion
-member (20.4.5.3/3) are required which is what was explicitly forbidden in
-DR #84. This is a bit amusing case in which removing ambiguity results with
-no candidates.
-</p>
-
-<p>
-I also found exception safety issue with auto_ptr related to auto_ptr_ref:
-</p>
-<pre>int f(auto_ptr&lt;B&gt;, std::string);
-auto_ptr&lt;B&gt; source2();
-
-// string constructor throws while auto_ptr_ref
-// "holds" the pointer
-int x4 = f(source2(), "xyz"); // #4
-</pre>
-
-<p>
-The theoretic execution sequence that will cause a leak:
-</p>
-<ol>
-<li>call auto_ptr&lt;B&gt;::operator auto_ptr_ref&lt;B&gt;()</li>
-<li>call string::string(char const*) and throw</li>
-</ol>
-
-<p>
-According to 20.4.5.3/3 and 20.4.5/2 the auto_ptr_ref conversion member
-returns auto_ptr_ref&lt;Y&gt; that holds *this and this is another defect since
-the type of *this is auto_ptr&lt;X&gt; where X might be different from Y. Several
-library vendors (e.g. SGI) implement auto_ptr_ref&lt;Y&gt; with Y* as member which
-is much more reasonable. Other vendor implemented auto_ptr_ref as
-defectively required and it results with awkward and catastrophic code:
-int oops = sink(auto_ptr&lt;B&gt;(source())); // warning recursive on all control
-paths
-</p>
-
-<p>
-Dave Abrahams noticed that there is no specification saying that
-auto_ptr_ref copy constructor can't throw.
-</p>
-
-<p>
-My proposal comes to solve all the above issues and significantly simplify
-auto_ptr implementation. One of the fundamental requirements from auto_ptr
-is that it can be constructed in an intuitive manner (i.e. like ordinary
-pointers) but with strict ownership semantics which yield that source
-auto_ptr in initialization must be non-const. My idea is to add additional
-constructor template with sole propose to generate ill-formed, diagnostic
-required, instance for const auto_ptr arguments during instantiation of
-declaration. This special constructor will not be instantiated for other
-types which is achievable using 14.8.2/2 (SFINAE). Having this constructor
-in hand makes the constructor template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;)
-legitimate since the actual argument can't be const yet non const r-value
-are acceptable.
-</p>
-
-<p>
-This implementation technique makes the "private auxiliary class"
-auto_ptr_ref obsolete and I found out that modern C++ compilers (e.g. EDG,
-GCC and VC) consume the new implementation as expected and allow all
-intuitive initialization and assignment cases while rejecting illegal cases
-that involve const auto_ptr arguments.
-</p>
-
-<p>The proposed auto_ptr interface:</p>
-
-<pre>namespace std {
- template&lt;class X&gt; class auto_ptr {
- public:
- typedef X element_type;
-
- // 20.4.5.1 construct/copy/destroy:
- explicit auto_ptr(X* p=0) throw();
- auto_ptr(auto_ptr&amp;) throw();
- template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp;) throw();
- auto_ptr&amp; operator=(auto_ptr&amp;) throw();
- template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;) throw();
- ~auto_ptr() throw();
-
- // 20.4.5.2 members:
- X&amp; operator*() const throw();
- X* operator-&gt;() const throw();
- X* get() const throw();
- X* release() throw();
- void reset(X* p=0) throw();
-
- private:
- template&lt;class U&gt;
- auto_ptr(U&amp; rhs, typename
-unspecified_error_on_const_auto_ptr&lt;U&gt;::type = 0);
- };
-}
-</pre>
-
-<p>
-One compliant technique to implement the unspecified_error_on_const_auto_ptr
-helper class is using additional private auto_ptr member class template like
-the following:
-</p>
-<pre>template&lt;typename T&gt; struct unspecified_error_on_const_auto_ptr;
-
-template&lt;typename T&gt;
-struct unspecified_error_on_const_auto_ptr&lt;auto_ptr&lt;T&gt; const&gt;
-{ typedef typename auto_ptr&lt;T&gt;::const_auto_ptr_is_not_allowed type; };
-</pre>
-
-<p>
-There are other techniques to implement this helper class that might work
-better for different compliers (i.e. better diagnostics) and therefore I
-suggest defining its semantic behavior without mandating any specific
-implementation. IMO, and I didn't found any compiler that thinks otherwise,
-14.7.1/5 doesn't theoretically defeat the suggested technique but I suggest
-verifying this with core language experts.
-</p>
-
-<p><b>Further changes in standard text:</b></p>
-<p>Remove section 20.4.5.3</p>
-
-<p>Change 20.4.5/2 to read something like:
-Initializing auto_ptr&lt;X&gt; from const auto_ptr&lt;Y&gt; will result with unspecified
-ill-formed declaration that will require unspecified diagnostic.</p>
-
-<p>Change 20.4.5.1/4,5,6 to read:</p>
-
-<pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt; const&amp; a) throw();</pre>
-<p> 4 Requires: Y* can be implicitly converted to X*.</p>
-<p> 5 Effects: Calls const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(a).release().</p>
-<p> 6 Postconditions: *this holds the pointer returned from a.release().</p>
-
-<p>Change 20.4.5.1/10</p>
-<pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt; a) throw();
-</pre>
-<p>
-10 Requires: Y* can be implicitly converted to X*. The expression delete
-get() is well formed.
-</p>
-
-<p>LWG TC DR #127 is obsolete.</p>
-
-<p>
-Notice that the copy constructor and copy assignment operator should remain
-as before and accept non-const auto_ptr&amp; since they have effect on the form
-of the implicitly declared copy constructor and copy assignment operator of
-class that contains auto_ptr as member per 12.8/5,10:
-</p>
-<pre>struct X {
- // implicit X(X&amp;)
- // implicit X&amp; operator=(X&amp;)
- auto_ptr&lt;D&gt; aptr_;
-};
-</pre>
-
-<p>
-In most cases this indicates about sloppy programming but preserves the
-current auto_ptr behavior.
-</p>
-
-<p>
-Dave Abrahams encouraged me to suggest fallback implementation in case that
-my suggestion that involves removing of auto_ptr_ref will not be accepted.
-In this case removing the obsolete conversion member to auto_ptr&lt;Y&gt; and
-20.4.5.3/4,5 is still required in order to eliminate ambiguity in legal
-cases. The two constructors that I suggested will co exist with the current
-members but will make auto_ptr_ref obsolete in initialization contexts.
-auto_ptr_ref will be effective in assignment contexts as suggested in DR
-#127 and I can't see any serious exception safety issues in those cases
-(although it's possible to synthesize such). auto_ptr_ref&lt;X&gt; semantics will
-have to be revised to say that it strictly holds pointer of type X and not
-reference to an auto_ptr for the favor of cases in which auto_ptr_ref&lt;Y&gt; is
-constructed from auto_ptr&lt;X&gt; in which X is different from Y (i.e. assignment
-from r-value derived to base).
-</p>
-
-<p><i>[Redmond: punt for the moment. We haven't decided yet whether we
- want to fix auto_ptr for C++-0x, or remove it and replace it with
- move_ptr and unique_ptr.]</i></p>
-
-
-<p><i>[
-Oxford 2007: Recommend NAD. We're just going to deprecate it. It still works for simple use cases
-and people know how to deal with it. Going forward <tt>unique_ptr</tt> is the recommended
-tool.
-]</i></p>
-
-
-<p><i>[
-2007-11-09: Reopened at the request of David Abrahams, Alisdair Meredith and Gabriel Dos Reis.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in D.9.1 [auto.ptr]:
-</p>
-
-<blockquote><pre>namespace std {
- <del>template &lt;class Y&gt; struct auto_ptr_ref {};</del>
-
- <ins>// exposition only</ins>
- <ins>template &lt;class T&gt; struct constant_object;</ins>
-
- <ins>// exposition only</ins>
- <ins>template &lt;class T&gt;</ins>
- <ins>struct cannot_transfer_ownership_from</ins>
- <ins>: constant_object&lt;T&gt; {};</ins>
-
- template &lt;class X&gt; class auto_ptr {
- public:
- typedef X element_type;
-
- // D.9.1.1 construct/copy/destroy:
- explicit auto_ptr(X* p =0) throw();
- auto_ptr(auto_ptr&amp;) throw();
- template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp;) throw();
- auto_ptr&amp; operator=(auto_ptr&amp;) throw();
- template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del>) throw();
- <del>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</del>
- ~auto_ptr() throw();
-
- // D.9.1.2 members:
- X&amp; operator*() const throw();
- X* operator-&gt;() const throw();
- X* get() const throw();
- X* release() throw();
- void reset(X* p =0) throw();
-
- <del>// D.9.1.3 conversions:</del>
- <del>auto_ptr(auto_ptr_ref&lt;X&gt;) throw();</del>
- <del>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() throw();</del>
- <del>template&lt;class Y&gt; operator auto_ptr&lt;Y&gt;() throw();</del>
-
- <ins>// exposition only</ins>
- <ins>template&lt;class U&gt;</ins>
- <ins>auto_ptr(U&amp; rhs, typename cannot_transfer_ownership_from&lt;U&gt;::error = 0);</ins>
- };
-
- template &lt;&gt; class auto_ptr&lt;void&gt;
- {
- public:
- typedef void element_type;
- };
-
-}
-</pre></blockquote>
-
-<p>
-Remove D.9.1.3 [auto.ptr.conv].
-</p>
-
-<p>
-Change D.9.1 [auto.ptr], p3:
-</p>
-
-<blockquote>
-The <tt>auto_ptr</tt> provides a semantics of strict ownership. An
-<tt>auto_ptr</tt> owns the object it holds a pointer to. Copying an
-<tt>auto_ptr</tt> copies the pointer and transfers ownership to the
-destination. If more than one <tt>auto_ptr</tt> owns the same object at
-the same time the behavior of the program is undefined. <ins>Templates
-<tt>constant_object</tt> and <tt>cannot_transfer_ownership_from</tt>,
-and the final constructor of <tt>auto_ptr</tt> are for exposition only.
-For any types <tt>X</tt> and <tt>Y</tt>, initializing
-<tt>auto_ptr&lt;X&gt;</tt> from <tt>const auto_ptr&lt;Y&gt;</tt> is
-ill-formed, diagnostic required.</ins> [<i>Note:</i> The uses of
-<tt>auto_ptr</tt> include providing temporary exception-safety for
-dynamically allocated memory, passing ownership of dynamically allocated
-memory to a function, and returning dynamically allocated memory from a
-function. <tt>auto_ptr</tt> does not meet the <tt>CopyConstructible</tt>
-and <tt>Assignable</tt> requirements for Standard Library container
-elements and thus instantiating a Standard Library container with an
-<tt>auto_ptr</tt> results in undefined behavior. <i>-- end note</i>]
-</blockquote>
-
-<p>
-Change D.9.1.1 [auto.ptr.cons], p5:
-</p>
-
-<blockquote>
-<pre>template&lt;class Y&gt; auto_ptr(auto_ptr&lt;Y&gt;<ins> const</ins>&amp; a) throw();
-</pre>
-<blockquote>
-<p>
-<i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
-</p>
-<p>
-<i>Effects:</i> Calls <ins><tt>const_cast&lt;auto_ptr&lt;Y&gt;&amp;&gt;(</tt></ins><tt>a</tt><ins><tt>)</tt></ins><tt>.release()</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>*this</tt> holds the pointer returned from <tt>a.release()</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-Change D.9.1.1 [auto.ptr.cons], p10:
-</p>
-
-<blockquote>
-<pre>template&lt;class Y&gt; auto_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del> a) throw();
-</pre>
-<blockquote>
-<p>
-<i>Requires:</i> <tt>Y*</tt> can be implicitly converted to <tt>X*</tt>.
-The expression <tt>delete get()</tt> is well formed.
-</p>
-<p>
-<i>Effects:</i> Calls <tt>reset(a.release())</tt>.
-</p>
-<p>
-<i>Returns:</i> <tt>*this</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="471"></a>471. result of what() implementation-defined</h3>
-<p><b>Section:</b> 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#type.info">issues</a> in [type.info].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>[lib.exception] specifies the following:</p>
-<pre> exception (const exception&amp;) throw();
- exception&amp; operator= (const exception&amp;) throw();
-
- -4- Effects: Copies an exception object.
- -5- Notes: The effects of calling what() after assignment
- are implementation-defined.
-</pre>
-
-<p>
-First, does the Note only apply to the assignment operator? If so,
-what are the effects of calling what() on a copy of an object? Is
-the returned pointer supposed to point to an identical copy of
-the NTBS returned by what() called on the original object or not?
-</p>
-
-<p>
-Second, is this Note intended to extend to all the derived classes
-in section 19? I.e., does the standard provide any guarantee for
-the effects of what() called on a copy of any of the derived class
-described in section 19?
-</p>
-
-<p>
-Finally, if the answer to the first question is no, I believe it
-constitutes a defect since throwing an exception object typically
-implies invoking the copy ctor on the object. If the answer is yes,
-then I believe the standard ought to be clarified to spell out
-exactly what the effects are on the copy (i.e., after the copy
-ctor was called).
-</p>
-
-<p><i>[Redmond: Yes, this is fuzzy. The issue of derived classes is
- fuzzy too.]</i></p>
-
-
-<p><i>[
-Batavia: Howard provided wording.
-]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Eric concerned this is unimplementable, due to nothrow guarantees.
-Suggested implementation would involve reference counting.
-</p>
-<p>
-Is the implied reference counting subtle enough to call out a note on
-implementation? Probably not.
-</p>
-<p>
-If reference counting required, could we tighten specification further
-to require same pointer value? Probably an overspecification, especially
-if exception classes defer evalutation of final string to calls to
-what().
-</p>
-<p>
-Remember issue moved open and not resolved at Batavia, but cannot
-remember who objected to canvas a disenting opinion - please speak up if
-you disagree while reading these minutes!
-</p>
-<p>
-Move to Ready as we are accepting words unmodified.
-</p>
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-The issue was pulled from Ready. It needs to make clear that only homogenous copying
-is intended to be supported. Not coping from a dervied to a base.
-</blockquote>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 18.7.1 [exception] to:
-</p>
-
-<blockquote>
-<pre>exception(const exception&amp; <ins><i>e</i></ins>) throw();
-exception&amp; operator=(const exception&amp; <ins><i>e</i></ins>) throw();</pre>
-<blockquote>
-<p>
--4- <i>Effects:</i> Copies an exception object.
-</p>
-<p>
-<del> -5- <i>Remarks:</i> The effects of calling what() after assignment are implementation-defined.</del>
-</p>
-<p>
-<ins>-5- <i>Throws:</i> Nothing. This also applies
-to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
-</p>
-<p>
-<ins>-7- <i>Postcondition:</i> <tt>strcmp(what(), <i>e</i>.what()) == 0</tt>. This also applies
-to all standard library-defined classes that derive from <tt>exception</tt>.</ins>
-</p>
-
-</blockquote>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="473"></a>473. underspecified ctype calls</h3>
-<p><b>Section:</b> 22.2.1.1 [locale.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-07-01</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Most ctype member functions come in two forms: one that operates
-on a single character at a time and another form that operates
-on a range of characters. Both forms are typically described by
-a single Effects and/or Returns clause.
-</p>
-<p>
-The Returns clause of each of the single-character non-virtual forms
-suggests that the function calls the corresponding single character
-virtual function, and that the array form calls the corresponding
-virtual array form. Neither of the two forms of each virtual member
-function is required to be implemented in terms of the other.
-</p>
-<p>
-There are three problems:
-</p>
-<p>
-1. One is that while the standard does suggest that each non-virtual
-member function calls the corresponding form of the virtual function,
-it doesn't actually explicitly require it.
-</p>
-<p>
-Implementations that cache results from some of the virtual member
-functions for some or all values of their arguments might want to
-call the array form from the non-array form the first time to fill
-the cache and avoid any or most subsequent virtual calls. Programs
-that rely on each form of the virtual function being called from
-the corresponding non-virtual function will see unexpected behavior
-when using such implementations.
-</p>
-<p>
-2. The second problem is that either form of each of the virtual
-functions can be overridden by a user-defined function in a derived
-class to return a value that is different from the one produced by
-the virtual function of the alternate form that has not been
-overriden.
-</p>
-<p>
-Thus, it might be possible for, say, ctype::widen(c) to return one
-value, while for ctype::widen(&amp;c, &amp;c + 1, &amp;wc) to set
-wc to another value. This is almost certainly not intended. Both
-forms of every function should be required to return the same result
-for the same character, otherwise the same program using an
-implementation that calls one form of the functions will behave
-differently than when using another implementation that calls the
-other form of the function "under the hood."
-</p>
-<p>
-3. The last problem is that the standard text fails to specify whether
-one form of any of the virtual functions is permitted to be implemented
-in terms of the other form or not, and if so, whether it is required
-or permitted to call the overridden virtual function or not.
-</p>
-<p>
-Thus, a program that overrides one of the virtual functions so that
-it calls the other form which then calls the base member might end
-up in an infinite loop if the called form of the base implementation
-of the function in turn calls the other form.
-</p>
-<p>
-Lillehammer: Part of this isn't a real problem. We already talk about
-caching. 22.1.1/6 But part is a real problem. ctype virtuals may call
-each other, so users don't know which ones to override to avoid avoid
-infinite loops.</p>
-
-<p>This is a problem for all facet virtuals, not just ctype virtuals,
-so we probably want a blanket statement in clause 22 for all
-facets. The LWG is leaning toward a blanket prohibition, that a
-facet's virtuals may never call each other. We might want to do that
-in clause 27 too, for that matter. A review is necessary. Bill will
-provide wording.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-<hr>
-<h3><a name="484"></a>484. Convertible to T</h3>
-<p><b>Section:</b> 24.1.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-09-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>From comp.std.c++:</p>
-
-<p>
-I note that given an input iterator a for type T,
-then *a only has to be "convertable to T", not actually of type T.
-</p>
-
-<p>Firstly, I can't seem to find an exact definition of "convertable to T".
-While I assume it is the obvious definition (an implicit conversion), I
-can't find an exact definition. Is there one?</p>
-
-<p>Slightly more worryingly, there doesn't seem to be any restriction on
-the this type, other than it is "convertable to T". Consider two input
-iterators a and b. I would personally assume that most people would
-expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that
-the standard requires that, and that whatever type *a is (call it U)
-could have == defined on it with totally different symantics and still
-be a valid inputer iterator.</p>
-
-<p>Is this a correct reading? When using input iterators should I write
-T(*a) all over the place to be sure that the object i'm using is the
-class I expect?</p>
-
-<p>This is especially a nuisance for operations that are defined to be
- "convertible to bool". (This is probably allowed so that
- implementations could return say an int and avoid an unnessary
- conversion. However all implementations I have seen simply return a
- bool anyway. Typical implemtations of STL algorithms just write
- things like <tt>while(a!=b &amp;&amp; *a!=0)</tt>. But strictly
- speaking, there are lots of types that are convertible to T but
- that also overload the appropriate operators so this doesn't behave
- as expected.</p>
-
-<p>If we want to make code like this legal (which most people seem to
- expect), then we'll need to tighten up what we mean by "convertible
- to T".</p>
-
-<p><i>[Lillehammer: The first part is NAD, since "convertible" is
- well-defined in core. The second part is basically about pathological
- overloads. It's a minor problem but a real one. So leave open for
- now, hope we solve it as part of iterator redesign.]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="485"></a>485. output iterator insufficently constrained</h3>
-<p><b>Section:</b> 24.1.2 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-10-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The note on 24.1.2 Output iterators insufficently limits what can be
-performed on output iterators. While it requires that each iterator is
-progressed through only once and that each iterator is written to only
-once, it does not require the following things:</p>
-
-<p>Note: Here it is assumed that x is an output iterator of type X which
-has not yet been assigned to.</p>
-
-<p>a) That each value of the output iterator is written to:
-The standard allows:
-++x; ++x; ++x;
-</p>
-
-<p>
-b) That assignments to the output iterator are made in order
-X a(x); ++a; *a=1; *x=2; is allowed
-</p>
-
-<p>
-c) Chains of output iterators cannot be constructed:
-X a(x); ++a; X b(a); ++b; X c(b); ++c; is allowed, and under the current
-wording (I believe) x,a,b,c could be written to in any order.
-</p>
-
-<p>I do not believe this was the intension of the standard?</p>
-<p><i>[Lillehammer: Real issue. There are lots of constraints we
- intended but didn't specify. Should be solved as part of iterator
- redesign.]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="492"></a>492. Invalid iterator arithmetic expressions</h3>
-<p><b>Section:</b> 23 [containers], 24 [iterators], 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Various clauses other than clause 25 make use of iterator arithmetic not
-supported by the iterator category in question.
-Algorithms in clause 25 are exceptional because of 25 [lib.algorithms],
-paragraph 9, but this paragraph does not provide semantics to the
-expression "iterator - n", where n denotes a value of a distance type
-between iterators.</p>
-
-<p>1) Examples of current wording:</p>
-
-<p>Current wording outside clause 25:</p>
-
-<p>
-23.2.2.4 [lib.list.ops], paragraphs 19-21: "first + 1", "(i - 1)",
-"(last - first)"
-23.3.1.1 [lib.map.cons], paragraph 4: "last - first"
-23.3.2.1 [lib.multimap.cons], paragraph 4: "last - first"
-23.3.3.1 [lib.set.cons], paragraph 4: "last - first"
-23.3.4.1 [lib.multiset.cons], paragraph 4: "last - first"
-24.4.1 [lib.reverse.iterators], paragraph 1: "(i - 1)"
-</p>
-
-<p>
-[Important note: The list is not complete, just an illustration. The
-same issue might well apply to other paragraphs not listed here.]</p>
-
-<p>None of these expressions is valid for the corresponding iterator
-category.</p>
-
-<p>Current wording in clause 25:</p>
-
-<p>
-25.1.1 [lib.alg.foreach], paragraph 1: "last - 1"
-25.1.3 [lib.alg.find.end], paragraph 2: "[first1, last1 -
-(last2-first2))"
-25.2.8 [lib.alg.unique], paragraph 1: "(i - 1)"
-25.2.8 [lib.alg.unique], paragraph 5: "(i - 1)"
-</p>
-
-<p>
-However, current wording of 25 [lib.algorithms], paragraph 9 covers
-neither of these four cases:</p>
-
-<p>Current wording of 25 [lib.algorithms], paragraph 9:</p>
-
-<p>
-"In the description of the algorithms operator + and - are used for some
-of the iterator categories for which they do not have to be defined. In
-these cases the semantics of a+n is the same as that of</p>
-<pre>{X tmp = a;
-advance(tmp, n);
-return tmp;
-}
-</pre>
-<p>and that of b-a is the same as of return distance(a, b)"</p>
-
-<p>
-This paragrpah does not take the expression "iterator - n" into account,
-where n denotes a value of a distance type between two iterators [Note:
-According to current wording, the expression "iterator - n" would be
-resolved as equivalent to "return distance(n, iterator)"]. Even if the
-expression "iterator - n" were to be reinterpreted as equivalent to
-"iterator + -n" [Note: This would imply that "a" and "b" were
-interpreted implicitly as values of iterator types, and "n" as value of
-a distance type], then 24.3.4/2 interfers because it says: "Requires: n
-may be negative only for random access and bidirectional iterators.",
-and none of the paragraphs quoted above requires the iterators on which
-the algorithms operate to be of random access or bidirectional category.
-</p>
-
-<p>2) Description of intended behavior:</p>
-
-<p>
-For the rest of this Defect Report, it is assumed that the expression
-"iterator1 + n" and "iterator1 - iterator2" has the semantics as
-described in current 25 [lib.algorithms], paragraph 9, but applying to
-all clauses. The expression "iterator1 - n" is equivalent to an
-result-iterator for which the expression "result-iterator + n" yields an
-iterator denoting the same position as iterator1 does. The terms
-"iterator1", "iterator2" and "result-iterator" shall denote the value of
-an iterator type, and the term "n" shall denote a value of a distance
-type between two iterators.</p>
-
-<p>
-All implementations known to the author of this Defect Report comply
-with these assumptions.
-No impact on current code is expected.</p>
-
-<p>3) Proposed fixes:</p>
-
-
-<p>Change 25 [lib.algorithms], paragraph 9 to:</p>
-
-<p>
-"In the description of the algorithms operator + and - are used for some
-of the iterator categories for which they do not have to be defined. In
-this paragraph, a and b denote values of an iterator type, and n denotes
-a value of a distance type between two iterators. In these cases the
-semantics of a+n is the same as that of</p>
-<pre>{X tmp = a;
-advance(tmp, n);
-return tmp;
-}
-</pre>
-<p>,the semantics of a-n denotes the value of an iterator i for which the
-following condition holds:
-advance(i, n) == a,
-and that of b-a is the same as of
-return distance(a, b)".
-</p>
-
-<p>Comments to the new wording:</p>
-
-<p>
-a) The wording " In this paragraph, a and b denote values of an iterator
-type, and n denotes a value of a distance type between two iterators."
-was added so the expressions "b-a" and "a-n" are distinguished regarding
-the types of the values on which they operate.
-b) The wording ",the semantics of a-n denotes the value of an iterator i
-for which the following condition holds: advance(i, n) == a" was added
-to cover the expression 'iterator - n'. The wording "advance(i, n) == a"
-was used to avoid a dependency on the semantics of a+n, as the wording
-"i + n == a" would have implied. However, such a dependency might well
-be deserved.
-c) DR 225 is not considered in the new wording.
-</p>
-
-<p>
-Proposed fixes regarding invalid iterator arithmetic expressions outside
-clause 25:</p>
-
-<p>
-Either
-a) Move modified 25 [lib.algorithms], paragraph 9 (as proposed above)
-before any current invalid iterator arithmetic expression. In that case,
-the first sentence of 25 [lib.algorithms], paragraph 9, need also to be
-modified and could read: "For the rest of this International Standard,
-...." / "In the description of the following clauses including this
-...." / "In the description of the text below ..." etc. - anyways
-substituting the wording "algorithms", which is a straight reference to
-clause 25.
-In that case, 25 [lib.algorithms] paragraph 9 will certainly become
-obsolete.
-Alternatively,
-b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
-paragraph 9, to the beginning of each clause containing invalid iterator
-arithmetic expressions.
-Alternatively,
-c) Fix each paragraph (both current wording and possible resolutions of
-DRs) containing invalid iterator arithmetic expressions separately.
-</p>
-
-<p>5) References to other DRs:</p>
-
-<p>
-See DR 225.
-See DR 237. The resolution could then also read "Linear in last -
-first".
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Keep open and ask Bill to provide wording.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p><i>[Lillehammer: Minor issue, but real. We have a blanket statement
-about this in 25/11. But (a) it should be in 17, not 25; and (b) it's
-not quite broad enough, because there are some arithmetic expressions
-it doesn't cover. Bill will provide wording.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="498"></a>498. Requirements for partition() and stable_partition() too strong</h3>
-<p><b>Section:</b> 25.2.13 [alg.partitions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Sean Parent, Joe Gottman <b>Date:</b> 2005-05-04</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Problem:
-The iterator requirements for partition() and stable_partition() [25.2.12]
-are listed as BidirectionalIterator, however, there are efficient algorithms
-for these functions that only require ForwardIterator that have been known
-since before the standard existed. The SGI implementation includes these (see
-<a href="http://www.sgi.com/tech/stl/partition.html">http://www.sgi.com/tech/stl/partition.html</a>
-and
-<a href="http://www.sgi.com/tech/stl/stable_partition.html">http://www.sgi.com/tech/stl/stable_partition.html</a>).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 25.2.12 from </p>
-<blockquote><pre>template&lt;class BidirectionalIterator, class Predicate&gt;
-BidirectionalIterator partition(BidirectionalIterato r first,
- BidirectionalIterator last,
- Predicate pred);
-</pre></blockquote>
-<p>to </p>
-<blockquote><pre>template&lt;class ForwardIterator, class Predicate&gt;
-ForwardIterator partition(ForwardIterator first,
- ForwardIterator last,
- Predicate pred);
-</pre></blockquote>
-<p>Change the complexity from </p>
-
-<blockquote><p>
-At most (last - first)/2 swaps are done. Exactly (last - first)
-applications of the predicate are done.
-</p></blockquote>
-
-<p>to </p>
-
-<blockquote><p>
-If ForwardIterator is a bidirectional_iterator, at most (last - first)/2
-swaps are done; otherwise at most (last - first) swaps are done. Exactly
-(last - first) applications of the predicate are done.
-</p></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Partition is a "foundation" algorithm useful in many contexts (like sorting
-as just one example) - my motivation for extending it to include forward
-iterators is slist - without this extension you can't partition an slist
-(without writing your own partition). Holes like this in the standard
-library weaken the argument for generic programming (ideally I'd be able
-to provide a library that would refine std::partition() to other concepts
-without fear of conflicting with other libraries doing the same - but
-that is a digression). I consider the fact that partition isn't defined
-to work for ForwardIterator a minor embarrassment.
-</p>
-
-<p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
-by next meeting. Sean provided further rationale by post-meeting
-mailing.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="502"></a>502. Proposition: Clarification of the interaction between a facet and an iterator</h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 2005-06-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Motivation:
-</p>
-
-<p>
-This requirement seems obvious to me, it is the essence of code modularity.
-I have complained to Mr. Plauger that the Dinkumware library does not
-observe this principle but he objected that this behaviour is not covered in
-the standard.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Append the following point to 22.1.1.1.1:
-</p>
-
-<p>
-6. The implementation of a facet of Table 52 parametrized with an
-InputIterator/OutputIterator should use that iterator only as character
-source/sink respectively.
-For a *_get facet, it means that the value received depends only on the
-sequence of input characters and not on how they are accessed.
-For a *_put facet, it means that the sequence of characters output depends
-only on the value to be formatted and not of how the characters are stored.
-</p>
-
-<p><i>[
-Berlin: Moved to Open, Need to clean up this area to make it clear
-locales don't have to contain open ended sets of facets. Jack, Howard,
-Bill.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="503"></a>503. more on locales</h3>
-<p><b>Section:</b> 22.2 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2005-06-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table
-51" to refer to the facet *objects* associated with a locale. And we
-almost certainly mean just those associated with the default or "C"
-locale. Otherwise, you can't switch to a locale that enforces a different
-mapping between narrow and wide characters, or that defines additional
-uppercase characters.
-</p>
-
-<p>
-b) 22.2.1.5 para. 3 (codecvt) has the same issues.
-</p>
-
-<p>
-c) 22.2.1.5.2 (do_unshift) is even worse. It *forbids* the generation of
-a homing sequence for the basic character set, which might very well need
-one.
-</p>
-
-<p>
-d) 22.2.1.5.2 (do_length) likewise dictates that the default mapping
-between wide and narrow characters be taken as one-for-one.
-</p>
-
-<p>
-e) 22.2.2 para. 2 (num_get/put) is both muddled and vacuous, as far as
-I can tell. The muddle is, as before, calling Table 51 a list of
-instantiations. But the constraint it applies seems to me to cover
-*all* defined uses of num_get/put, so why bother to say so?
-</p>
-
-<p>
-f) 22.2.3.1.2 para. 1(do_decimal_point) says "The required instantiations
-return '.' or L'.'.) Presumably this means "as appropriate for the
-character type. But given the vague definition of "required" earlier,
-this overrules *any* change of decimal point for non "C" locales.
-Surely we don't want to do that.
-</p>
-
-<p>
-g) 22.2.3.1.2 para. 2 (do_thousands_sep) says "The required instantiations
-return ',' or L','.) As above, this probably means "as appropriate for the
-character type. But this overrules the "C" locale, which requires *no*
-character ('\0') for the thousands separator. Even if we agree that we
-don't mean to block changes in decimal point or thousands separator,
-we should also eliminate this clear incompatibility with C.
-</p>
-
-<p>
-h) 22.2.3.1.2 para. 2 (do_grouping) says "The required instantiations
-return the empty string, indicating no grouping." Same considerations
-as for do_decimal_point.
-</p>
-
-<p>
-i) 22.2.4.1 para. 1 (collate) refers to "instantiations required in Table
-51". Same bad jargon.
-</p>
-
-<p>
-j) 22.2.4.1.2 para. 1 (do_compare) refers to "instantiations required
-in Table 51". Same bad jargon.
-</p>
-
-<p>
-k) 22.2.5 para. 1 (time_get/put) uses the same muddled and vacuous
-as num_get/put.
-</p>
-
-<p>
-l) 22.2.6 para. 2 (money_get/put) uses the same muddled and vacuous
-as num_get/put.
-</p>
-
-<p>
-m) 22.2.6.3.2 (do_pos/neg_format) says "The instantiations required
-in Table 51 ... return an object of type pattern initialized to
-{symbol, sign, none, value}." This once again *overrides* the "C"
-locale, as well as any other locale."
-</p>
-
-<p>
-3) We constrain the use_facet calls that can be made by num_get/put,
-so why don't we do the same for money_get/put? Or for any of the
-other facets, for that matter?
-</p>
-
-<p>
-4) As an almost aside, we spell out when a facet needs to use the ctype
-facet, but several also need to use a codecvt facet and we don't say so.
-</p>
-<p><i>[
-Berlin: Bill to provide wording.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="522"></a>522. Tuple doesn't define swap</h3>
-<p><b>Section:</b> 20.4 [tuple], TR1 6.1 [tr.tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Andy Koenig <b>Date:</b> 2005-07-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Tuple doesn't define swap(). It should.
-</p>
-<p><i>[
-Berlin: Doug to provide wording.
-]</i></p>
-
-<p><i>[
-Batavia: Howard to provide wording.
-]</i></p>
-
-<p><i>[
-Toronto: Howard to provide wording (really this time).
-]</i></p>
-
-
-<p><i>[
-Bellevue: Alisdair provided wording.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Add these signatures to 20.4 [tuple]
-</p>
-
-<blockquote><pre>template &lt;class... Types&gt;
- void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
-template &lt;class... Types&gt;
- void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
-template &lt;class... Types&gt;
- void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y);
-</pre></blockquote>
-
-<p>
-Add this signature to 20.4.1 [tuple.tuple]
-</p>
-
-<blockquote><pre>void swap(tuple&amp;&amp;);
-</pre></blockquote>
-
-<p>
-Add the following two sections to the end of the tuple clauses
-</p>
-
-<blockquote>
-<p>
-20.3.1.7 tuple swap [tuple.swap]
-</p>
-
-<pre>void swap(tuple&amp;&amp; rhs);
-</pre>
-
-<blockquote>
-<p>
-<i>Requires:</i> Each type in <tt>Types</tt> shall be <tt>Swappable</tt>.
-</p>
-<p>
-<i>Effects:</i> Calls <tt>swap</tt> for each element in <tt>*this</tt> and its corresponding element
-in <tt>rhs</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing, unless one of the element-wise <tt>swap</tt> calls throw an
-exception.
-</p>
-</blockquote>
-
-<p>
-20.3.1.8 tuple specialized algorithms [tuple.special]
-</p>
-
-<pre>template &lt;class... Types&gt;
- void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp; y);
-template &lt;class... Types&gt;
- void swap(tuple&lt;Types...&gt;&amp;&amp; x, tuple&lt;Types...&gt;&amp; y);
-template &lt;class... Types&gt;
- void swap(tuple&lt;Types...&gt;&amp; x, tuple&lt;Types...&gt;&amp;&amp; y);
-</pre>
-
-<blockquote>
-<p>
-<i>Effects:</i> x.swap(y)
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="523"></a>523. regex case-insensitive character ranges are unimplementable as specified</h3>
-<p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Eric Niebler <b>Date:</b> 2005-07-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-A problem with TR1 regex is currently being discussed on the Boost
-developers list. It involves the handling of case-insensitive matching
-of character ranges such as [Z-a]. The proper behavior (according to the
-ECMAScript standard) is unimplementable given the current specification
-of the TR1 regex_traits&lt;&gt; class template. John Maddock, the author of
-the TR1 regex proposal, agrees there is a problem. The full discussion
-can be found at http://lists.boost.org/boost/2005/06/28850.php (first
-message copied below). We don't have any recommendations as yet.
-</p>
-<p>
--- Begin original message --
-</p>
-<p>
-The situation of interest is described in the ECMAScript specification
-(ECMA-262), section 15.10.2.15:
-</p>
-<p>
-"Even if the pattern ignores case, the case of the two ends of a range
-is significant in determining which characters belong to the range.
-Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
-e, and f, while the pattern /[E-f]/i matches all upper and lower-case
-ASCII letters as well as the symbols [, \, ], ^, _, and `."
-</p>
-<p>
-A more interesting case is what should happen when doing a
-case-insentitive match on a range such as [Z-a]. It should match z, Z,
-a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
-Boost.Regex (it throws an exception from the regex constructor).
-</p>
-<p>
-The tough pill to swallow is that, given the specification in TR1, I
-don't think there is any effective way to handle this situation.
-According to the spec, case-insensitivity is handled with
-regex_traits&lt;&gt;::translate_nocase(CharT) -- two characters are equivalent
-if they compare equal after both are sent through the translate_nocase
-function. But I don't see any way of using this translation function to
-make character ranges case-insensitive. Consider the difficulty of
-detecting whether "z" is in the range [Z-a]. Applying the transformation
-to "z" has no effect (it is essentially std::tolower). And we're not
-allowed to apply the transformation to the ends of the range, because as
-ECMA-262 says, "the case of the two ends of a range is significant."
-</p>
-<p>
-So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
-is to redefine translate_nocase to return a string_type containing all
-the characters that should compare equal to the specified character. But
-this function is hard to implement for Unicode, and it doesn't play nice
-with the existing ctype facet. What a mess!
-</p>
-<p>
--- End original message --
-</p>
-
-<p><i>[
-John Maddock adds:
-]</i></p>
-
-
-<p>
-One small correction, I have since found that ICU's regex package does
-implement this correctly, using a similar mechanism to the current
-TR1.Regex.
-</p>
-<p>
-Given an expression [c1-c2] that is compiled as case insensitive it:
-</p>
-<p>
-Enumerates every character in the range c1 to c2 and converts it to it's
-case folded equivalent. That case folded character is then used a key to a
-table of equivalence classes, and each member of the class is added to the
-list of possible matches supported by the character-class. This second step
-isn't possible with our current traits class design, but isn't necessary if
-the input text is also converted to a case-folded equivalent on the fly.
-</p>
-<p>
-ICU applies similar brute force mechanisms to character classes such as
-[[:lower:]] and [[:word:]], however these are at least cached, so the impact
-is less noticeable in this case.
-</p>
-<p>
-Quick and dirty performance comparisons show that expressions such as
-"[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times
-slower than a "normal" expression). For an application that uses a lot of
-regexes this could have a noticeable performance impact. ICU also has an
-advantage in that it knows the range of valid characters codes: code points
-outside that range are assumed not to require enumeration, as they can not
-be part of any equivalence class. I presume that if we want the TR1.Regex
-to work with arbitrarily large character sets enumeration really does become
-impractical.
-</p>
-<p>
-Finally note that Unicode has:
-</p>
-<p>
-Three cases (upper, lower and title).
-One to many, and many to one case transformations.
-Character that have context sensitive case translations - for example an
-uppercase sigma has two different lowercase forms - the form chosen depends
-on context(is it end of a word or not), a caseless match for an upper case
-sigma should match either of the lower case forms, which is why case folding
-is often approximated by tolower(toupper(c)).
-</p>
-<p>
-Probably we need some way to enumerate character equivalence classes,
-including digraphs (either as a result or an input), and some way to tell
-whether the next character pair is a valid digraph in the current locale.
-</p>
-<p>
-Hoping this doesn't make this even more complex that it was already,
-</p>
-
-<p><i>[
-Portland: Alisdair: Detect as invalid, throw an exception.
-Pete: Possible general problem with case insensitive ranges.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="539"></a>539. partial_sum and adjacent_difference should mention requirements</h3>
-<p><b>Section:</b> 26.6.3 [partial.sum] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 2006-02-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There are some problems in the definition of partial_sum and
-adjacent_difference in 26.4 [lib.numeric.ops]
-</p>
-
-<p>
-Unlike <tt>accumulate</tt> and <tt>inner_product</tt>, these functions are not
-parametrized on a "type T", instead, 26.4.3 [lib.partial.sum] simply
-specifies the effects clause as;
-</p>
-
-<blockquote><p>
-Assigns to every element referred to by iterator <tt>i</tt> in the range
-<tt>[result,result + (last - first))</tt> a value correspondingly equal to
-</p>
-<blockquote><pre>((...(* first + *( first + 1)) + ...) + *( first + ( i - result )))
-</pre></blockquote>
-</blockquote>
-
-<p>
-And similarly for BinaryOperation. Using just this definition, it seems
-logical to expect that:
-</p>
-
-
-<blockquote><pre>char i_array[4] = { 100, 100, 100, 100 };
-int o_array[4];
-
-std::partial_sum(i_array, i_array+4, o_array);
-</pre></blockquote>
-
-<p>
-Is equivalent to
-</p>
-
-<blockquote><pre>int o_array[4] = { 100, 100+100, 100+100+100, 100+100+100+100 };
-</pre></blockquote>
-
-<p>
-i.e. 100, 200, 300, 400, with addition happening in the <tt>result type</tt>,
-<tt>int</tt>.
-</p>
-
-<p>
-Yet all implementations I have tested produce 100, -56, 44, -112,
-because they are using an accumulator of the <tt>InputIterator</tt>'s
-<tt>value_type</tt>, which in this case is <tt>char</tt>, not <tt>int</tt>.
-</p>
-
-<p>
-The issue becomes more noticeable when the result of the expression <tt>*i +
-*(i+1)</tt> or <tt>binary_op(*i, *i-1)</tt> can't be converted to the
-<tt>value_type</tt>. In a contrived example:
-</p>
-
-<blockquote><pre>enum not_int { x = 1, y = 2 };
-...
-not_int e_array[4] = { x, x, y, y };
-std::partial_sum(e_array, e_array+4, o_array);
-</pre></blockquote>
-
-<p>
-Is it the intent that the operations happen in the <tt>input type</tt>, or in
-the <tt>result type</tt>?
-</p>
-
-<p>
-If the intent is that operations happen in the <tt>result type</tt>, something
-like this should be added to the "Requires" clause of 26.4.3/4
-[lib.partial.sum]:
-</p>
-
-<blockquote><p>
-The type of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall meet the
-requirements of <tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt>
-(23.1) types.
-</p></blockquote>
-
-<p>
-(As also required for <tt>T</tt> in 26.4.1 [lib.accumulate] and 26.4.2
-[lib.inner.product].)
-</p>
-
-<p>
-The "auto initializer" feature proposed in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1894.pdf">N1894</a>
-is not required to
-implement <tt>partial_sum</tt> this way. The 'narrowing' behaviour can still be
-obtained by using the <tt>std::plus&lt;&gt;</tt> function object.
-</p>
-
-<p>
-If the intent is that operations happen in the <tt>input type</tt>, then
-something like this should be added instead;
-</p>
-
-<blockquote><p>
-The type of *first shall meet the requirements of
-<tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types.
-The result of <tt>*i + *(i+1)</tt> or <tt>binary_op(*i, *(i+1))</tt> shall be
-convertible to this type.
-</p></blockquote>
-
-<p>
-The 'widening' behaviour can then be obtained by writing a custom proxy
-iterator, which is somewhat involved.
-</p>
-
-<p>
-In both cases, the semantics should probably be clarified.
-</p>
-
-<p>
-26.4.4 [lib.adjacent.difference] is similarly underspecified, although
-all implementations seem to perform operations in the 'result' type:
-</p>
-
-<blockquote><pre>unsigned char i_array[4] = { 4, 3, 2, 1 };
-int o_array[4];
-
-std::adjacent_difference(i_array, i_array+4, o_array);
-</pre></blockquote>
-
-<p>
-o_array is 4, -1, -1, -1 as expected, not 4, 255, 255, 255.
-</p>
-
-<p>
-In any case, <tt>adjacent_difference</tt> doesn't mention the requirements on the
-<tt>value_type</tt>; it can be brought in line with the rest of 26.4
-[lib.numeric.ops] by adding the following to 26.4.4/2
-[lib.adjacent.difference]:
-</p>
-
-<blockquote><p>
-The type of <tt>*first</tt> shall meet the requirements of
-<tt>CopyConstructible</tt> (20.1.3) and <tt>Assignable</tt> (23.1) types."
-</p></blockquote>
-<p><i>[
-Berlin: Giving output iterator's value_types very controversial. Suggestion of
-adding signatures to allow user to specify "accumulator".
-]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-The intent of the algorithms is to perform their calculations using the type of the input iterator.
-Proposed wording provided.
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-We did not agree that the proposed resolution was correct. For example,
-when the arguments are types <tt>(float*, float*, double*)</tt>, the
-highest-quality solution would use double as the type of the
-accumulator. If the intent of the wording is to require that the type of
-the accumulator must be the <tt>input_iterator</tt>'s <tt>value_type</tt>, the wording
-should specify it.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to section 26.6.3 [partial.sum] paragraph 4 the following two sentences:
-</p>
-
-<blockquote>
-The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
-(20.1.3?) and <tt>Assignable</tt> (23.1?) types. The result of <tt>*i + *(i+1)</tt> or
-<tt>binary_op(*i, *(i+1))</tt> shall be convertible to this type.
-</blockquote>
-
-<p>
-Add to section 26.6.4 [adjacent.difference] paragraph 2 the following sentence:
-</p>
-
-<blockquote>
-The type of <tt>*first</tt> shall meet the requirements of <tt>CopyConstructible</tt>?
-(20.1.3) and <tt>Assignable</tt> (23.1) types.
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="546"></a>546. _Longlong and _ULonglong are integer types</h3>
-<p><b>Section:</b> TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The TR sneaks in two new integer types, _Longlong and _Ulonglong, in [tr.c99].
-The rest of the TR should use that type. I believe this affects two places.
-First, the random number requirements, 5.1.1/10-11, lists all of the types with
-which template parameters named IntType and UIntType may be instantiated.
-_Longlong (or "long long", assuming it is added to C++0x) should be added to the
-IntType list, and UIntType (again, or "unsigned long long") should be added to
-the UIntType list. Second, 6.3.2 lists the types for which hash&lt;&gt; is
-required to be instantiable. _Longlong and _Ulonglong should be added to that
-list, so that people may use long long as a hash key.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="556"></a>556. is Compare a BinaryPredicate?</h3>
-<p><b>Section:</b> 25.3 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 25, p8 we allow BinaryPredicates to return a type that's convertible
-to bool but need not actually be bool. That allows predicates to return
-things like proxies and requires that implementations be careful about
-what kinds of expressions they use the result of the predicate in (e.g.,
-the expression in if (!pred(a, b)) need not be well-formed since the
-negation operator may be inaccessible or return a type that's not
-convertible to bool).
-</p>
-<p>
-Here's the text for reference:
-</p>
-<blockquote><p>
- ...if an algorithm takes BinaryPredicate binary_pred as its argument
- and first1 and first2 as its iterator arguments, it should work
- correctly in the construct if (binary_pred(*first1, first2)){...}.
-</p></blockquote>
-
-<p>
-In 25.3, p2 we require that the Compare function object return true
-of false, which would seem to preclude such proxies. The relevant text
-is here:
-</p>
-<blockquote><p>
- Compare is used as a function object which returns true if the first
- argument is less than the second, and false otherwise...
-</p></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-I think we could fix this by rewording 25.3, p2 to read somthing like:
-</p>
-<blockquote><p>
--2- <tt>Compare</tt> is <del>used as a function object which returns
-<tt>true</tt> if the first argument</del> <ins>a <tt>BinaryPredicate</tt>. The
-return value of the function call operator applied to an object of type
-<tt>Compare</tt>, when converted to type <tt>bool</tt>, yields <tt>true</tt>
-if the first argument of the call</ins> is less than the second, and
-<tt>false</tt> otherwise. <tt>Compare <i>comp</i></tt> is used throughout for
-algorithms assuming an ordering relation. It is assumed that <tt><i>comp</i></tt>
-will not apply any non-constant function through the dereferenced iterator.
-</p></blockquote>
-
-
-<p><i>[
-Portland: Jack to define "convertible to bool" such that short circuiting isn't
-destroyed.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="564"></a>564. stringbuf seekpos underspecified</h3>
-<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The effects of the <code>seekpos()</code> member function of
-<code>basic_stringbuf</code> simply say that the function positions
-the input and/or output sequences but fail to spell out exactly
-how. This is in contrast to the detail in which <code>seekoff()</code>
-is described.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-Change 27.7.1.3, p13 to read:
-
- </p>
-<blockquote>
-<p>
--13- <i>Effects:</i> <ins>Same as <tt>seekoff(off_type(<i>sp</i>), ios_base::beg,
-<i>which</i>)</tt>.</ins> <del>Alters the stream position within the controlled sequences,
-if possible, to correspond to the stream position stored in <tt><i>sp</i></tt>
-(as described below).</del>
-</p>
-<ul>
-<li><del>If <tt>(<i>which</i> &amp; ios_base::in) != 0</tt>, positions the input sequence.</del></li>
-<li><del>If <tt>(<i>which</i> &amp; ios_base::out) != 0</tt>, positions the output sequence.</del></li>
-<li><del>If <tt><i>sp</i></tt> is an invalid stream position, or if the function
-positions neither sequence, the positioning operation fails. If <tt><i>sp</i></tt>
-has not been obtained by a previous successful call to one of the positioning
-functions (<tt>seekoff</tt>, <tt>seekpos</tt>, <tt>tellg</tt>, <tt>tellp</tt>)
-the effect is undefined.</del></li>
-</ul>
-</blockquote>
-
-
-<p><i>[
-Kona (2007): A <tt>pos_type</tt> is a position in a stream by
-definition, so there is no ambiguity as to what it means. Proposed
-Disposition: NAD
-]</i></p>
-
-
-<p><i>[
-Post-Kona Martin adds:
-I'm afraid I disagree
-with the Kona '07 rationale for marking it NAD. The only text
-that describes precisely what it means to position the input
-or output sequence is in <tt>seekoff()</tt>. The <tt>seekpos()</tt> Effects
-clause is inadequate in comparison and the proposed resolution
-plugs the hole by specifying <tt>seekpos()</tt> in terms of <tt>seekoff()</tt>.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="565"></a>565. xsputn inefficient</h3>
-<p><b>Section:</b> 27.5.2.4.5 [streambuf.virt.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-<tt>streambuf::xsputn()</tt> is specified to have the effect of
-"writing up to <tt>n</tt> characters to the output sequence as if by
-repeated calls to <tt>sputc(c)</tt>."
-
- </p>
- <p>
-
-Since <tt>sputc()</tt> is required to call <tt>overflow()</tt> when
-<tt>(pptr() == epptr())</tt> is true, strictly speaking
-<tt>xsputn()</tt> should do the same. However, doing so would be
-suboptimal in some interesting cases, such as in unbuffered mode or
-when the buffer is <tt>basic_stringbuf</tt>.
-
- </p>
- <p>
-
-Assuming calling <tt>overflow()</tt> is not really intended to be
-required and the wording is simply meant to describe the general
-effect of appending to the end of the sequence it would be worthwhile
-to mention in <tt>xsputn()</tt> that the function is not actually
-required to cause a call to <tt>overflow()</tt>.
-
- </p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-Add the following sentence to the <tt>xsputn()</tt> Effects clause in
-27.5.2.4.5, p1 (N1804):
-
- </p>
- <blockquote>
- <p>
--1- <i>Effects:</i> Writes up to <tt><i>n</i></tt> characters to the output
-sequence as if by repeated calls to <tt>sputc(<i>c</i>)</tt>. The characters
-written are obtained from successive elements of the array whose first element
-is designated by <tt><i>s</i></tt>. Writing stops when either <tt><i>n</i></tt>
-characters have been written or a call to <tt>sputc(<i>c</i>)</tt> would return
-<tt>traits::eof()</tt>. <ins>It is uspecified whether the function calls
-<tt>overflow()</tt> when <tt>(pptr() == epptr())</tt> becomes true or whether
-it achieves the same effects by other means.</ins>
- </p>
- </blockquote>
- <p>
-
-In addition, I suggest to add a footnote to this function with the
-same text as Footnote 292 to make it extra clear that derived classes
-are permitted to override <tt>xsputn()</tt> for efficiency.
-
- </p>
-
-
-<p><i>[
-Kona (2007): We want to permit a <tt>streambuf</tt> that streams output directly
-to a device without making calls to <tt>sputc</tt> or <tt>overflow</tt>. We believe that
-has always been the intention of the committee. We believe that the
-proposed wording doesn't accomplish that. Proposed Disposition: Open
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="568"></a>568. log2 overloads missing</h3>
-<p><b>Section:</b> TR1 8.16.4 [tr.c99.cmath.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-03-07</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>log2</tt> is missing from the list of "additional overloads" in TR1 8.16.4 [tr.c99.cmath.over] p1.
-</p>
-
-<p>
-Hinnant: This is a TR1 issue only. It is fixed in the current (N2135) WD.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add <tt>log2</tt> to the list of functions in TR1 8.16.4 [tr.c99.cmath.over] p1.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="573"></a>573. C++0x file positioning should handle modern file sizes</h3>
-<p><b>Section:</b> 27.4.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There are two deficiencies related to file sizes:
-</p>
-<ol>
-<li>It doesn't appear that the Standard Library is specified in
- a way that handles modern file sizes, which are often too
- large to be represented by an unsigned long.</li>
-
-<li>The std::fpos class does not currently have the ability to
- set/get file positions.</li>
-</ol>
-<p>
-The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by:
-</p>
-<ol type="A">
-<li>Defining fpos_t be long long, which is large enough to
- represent any file position likely in the foreseeable future.</li>
-
-<li>Adding member functions to class fpos. For example,
-<blockquote><pre>fpos_t seekpos() const;
-</pre></blockquote>
-</li>
-</ol>
-<p>
-Because there are so many types relating to file positions and offsets (fpos_t,
-fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and
-perhaps more), it is difficult to know if the Dinkumware extensions are
-sufficient. But they seem a useful starting place for discussions, and they do
-represent existing practice.
-</p>
-
-<p><i>[
-Kona (2007): We need a paper. It would be nice if someone proposed
-clarifications to the definitions of <tt>pos_type</tt> and <tt>off_type</tt>. Currently
-these definitions are horrible. Proposed Disposition: Open
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="580"></a>580. unused allocator members</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a></p>
-<p><b>Discussion:</b></p>
- <p>
-
-C++ Standard Library templates that take an allocator as an argument
-are required to call the <code>allocate()</code> and
-<code>deallocate()</code> members of the allocator object to obtain
-storage. However, they do not appear to be required to call any other
-allocator members such as <code>construct()</code>,
-<code>destroy()</code>, <code>address()</code>, and
-<code>max_size()</code>. This makes these allocator members less than
-useful in portable programs.
-
- </p>
- <p>
-
-It's unclear to me whether the absence of the requirement to use these
-allocator members is an unintentional omission or a deliberate
-choice. However, since the functions exist in the standard allocator
-and since they are required to be provided by any user-defined
-allocator I believe the standard ought to be clarified to explictly
-specify whether programs should or should not be able to rely on
-standard containers calling the functions.
-
- </p>
- <p>
-
-I propose that all containers be required to make use of these
-functions.
-
- </p>
-<p><i>[
-Batavia: We support this resolution. Martin to provide wording.
-]</i></p>
-
-<p><i>[
-pre-Oxford: Martin provided wording.
-]</i></p>
-
-
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-Specifically, I propose to change 23.1 [container.requirements],
-p9 as follows:
-
- </p>
- <blockquote>
-<p>
--9- Copy constructors for all container types defined in this clause
-<ins>that are parametrized on <code>Allocator</code></ins> copy
-<del>an</del><ins>the</ins> allocator argument from their respective
-first parameters.
-
-All other constructors for these container types take a<del>n</del>
-<ins>const</ins> <code>Allocator&amp;</code> argument (20.1.6), an
-allocator whose <code>value_type</code> is the same as the container's
-<code>value_type</code>.
-
-A copy of this argument <del>is</del><ins>shall be</ins> used for any
-memory allocation <ins> and deallocation</ins> performed<del>,</del>
-by these constructors and by all member functions<del>,</del> during
-the lifetime of each container object. <ins>Allocation shall be
-performed "as if" by calling the <code>allocate()</code> member
-function on a copy of the allocator object of the appropriate type
-<sup>New Footnote)</sup>, and deallocation "as if" by calling
-<code>deallocate()</code> on a copy of the same allocator object of
-the corresponding type.</ins>
-
-<ins>A copy of this argument shall also be used to construct and
-destroy objects whose lifetime is managed by the container, including
-but not limited to those of the container's <code>value_type</code>,
-and to obtain their address. All objects residing in storage
-allocated by a container's allocator shall be constructed "as if" by
-calling the <code>construct()</code> member function on a copy of the
-allocator object of the appropriate type. The same objects shall be
-destroyed "as if" by calling <code>destroy()</code> on a copy of the
-same allocator object of the same type. The address of such objects
-shall be obtained "as if" by calling the <code>address()</code> member
-function on a copy of the allocator object of the appropriate
-type.</ins>
-
-<ins>Finally, a copy of this argument shall be used by its container
-object to determine the maximum number of objects of the container's
-<code>value_type</code> the container may store at the same time. The
-container member function <code>max_size()</code> obtains this number
-from the value returned by a call to
-<code>get_allocator().max_size()</code>.</ins>
-
-In all container types defined in this clause <ins>that are
-parametrized on <code>Allocator</code></ins>, the member
-<code>get_allocator()</code> returns a copy of the
-<code>Allocator</code> object used to construct the
-container.<sup>258)</sup>
-</p>
-<p>
-New Footnote: This type may be different from <code>Allocator</code>:
-it may be derived from <code>Allocator</code> via
-<code>Allocator::rebind&lt;U&gt;::other</code> for the appropriate
-type <code>U</code>.
-</p>
- </blockquote>
- <p>
-
-The proposed wording seems cumbersome but I couldn't think of a better
-way to describe the requirement that containers use their
-<code>Allocator</code> to manage only objects (regardless of their
-type) that persist over their lifetimes and not, for example,
-temporaries created on the stack. That is, containers shouldn't be
-required to call <code>Allocator::construct(Allocator::allocate(1),
-elem)</code> just to construct a temporary copy of an element, or
-<code>Allocator::destroy(Allocator::address(temp), 1)</code> to
-destroy temporaries.
-
- </p>
-
-
-<p><i>[
-Howard: This same paragraph will need some work to accommodate <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
-]</i></p>
-
-
-<p><i>[
-post Oxford: This would be rendered NAD Editorial by acceptance of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="582"></a>582. specialized algorithms and volatile storage</h3>
-<p><b>Section:</b> 20.7.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The specialized algorithms [lib.specialized.algorithms] are specified
-as having the general effect of invoking the following expression:
-
- </p>
- <pre>
-new (static_cast&lt;void*&gt;(&amp;*i))
- typename iterator_traits&lt;ForwardIterator&gt;::value_type (x)
-
- </pre>
- <p>
-
-This expression is ill-formed when the type of the subexpression
-<code>&amp;*i</code> is some volatile-qualified <code>T</code>.
-
- </p>
-
-<p><i>[
-Batavia: Lack of support for proposed resolution but agree there is a
-defect. Howard to look at wording. Concern that move semantics
-properly expressed if iterator returns rvalue.
-]</i></p>
-
-
-
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-In order to allow these algorithms to operate on volatile storage I
-propose to change the expression so as to make it well-formed even for
-pointers to volatile types. Specifically, I propose the following
-changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:
-
- </p>
- <pre>
-<i>Effects</i>:
-
-typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer pointer;
-typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
-
-for (; first != last; ++result, ++first)
- new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*result))
- value_type (*first);
-
- </pre>
- <p>
-
-change 20.6.4.2, p1 to read
-
- </p>
- <pre>
-<i>Effects</i>:
-
-typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer pointer;
-typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
-
-for (; first != last; ++result, ++first)
- new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
- value_type (*x);
-
- </pre>
- <p>
-
-and change 20.6.4.3, p1 to read
-
- </p>
- <pre>
-<i>Effects</i>:
-
-typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer pointer;
-typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;
-
-for (; n--; ++first)
- new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
- value_type (*x);
-
- </pre>
- <p>
-
-In addition, since there is no partial specialization for
-<code>iterator_traits&lt;volatile T*&gt;</code> I propose to add one
-to parallel such specialization for &lt;const T*&gt;. Specifically, I
-propose to add the following text to the end of 24.3.1, p3:
-
- </p>
- <p>
-
-and for pointers to volatile as
-
- </p>
- <pre>
-namespace std {
-template&lt;class T&gt; struct iterator_traits&lt;volatile T*&gt; {
-typedef ptrdiff_t difference_type;
-typedef T value_type;
-typedef volatile T* pointer;
-typedef volatile T&amp; reference;
-typedef random_access_iterator_tag iterator_category;
-};
-}
-
- </pre>
- <p>
-
-Note that the change to <code>iterator_traits</code> isn't necessary
-in order to implement the specialized algorithms in a way that allows
-them to operate on volatile strorage. It is only necesassary in order
-to specify their effects in terms of <code>iterator_traits</code> as
-is done here. Implementations can (and some do) achieve the same
-effect by means of function template overloading.
-
- </p>
-
-
-
-
-<hr>
-<h3><a name="585"></a>585. facet error reporting</h3>
-<p><b>Section:</b> 22.2 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor, Paolo Carlini <b>Date:</b> 2006-06-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-Section 22.2, paragraph 2 requires facet <code>get()</code> members
-that take an <code>ios_base::iostate&amp;</code> argument,
-<code><i>err</i></code>, to ignore the (initial) value of the
-argument, but to set it to <code>ios_base::failbit</code> in case of a
-parse error.
-
- </p>
- <p>
-
-We believe there are a few minor problems with this blanket
-requirement in conjunction with the wording specific to each
-<code>get()</code> member function.
-
- </p>
- <p>
-
-First, besides <code>get()</code> there are other member functions
-with a slightly different name (for example,
-<code>get_date()</code>). It's not completely clear that the intent of
-the paragraph is to include those as well, and at least one
-implementation has interpreted the requirement literally.
-
- </p>
- <p>
-
-Second, the requirement to "set the argument to
-<code>ios_base::failbit</code> suggests that the functions are not
-permitted to set it to any other value (such as
-<code>ios_base::eofbit</code>, or even <code>ios_base::eofbit |
-ios_base::failbit</code>).
-
- </p>
- <p>
-
-However, 22.2.2.1.2, p5 (Stage 3 of <code>num_get</code> parsing) and
-p6 (<code>bool</code> parsing) specifies that the <code>do_get</code>
-functions perform <code><i>err</i> |= ios_base::eofbit</code>, which
-contradicts the earlier requirement to ignore <i>err</i>'s initial
-value.
-
- </p>
- <p>
-
-22.2.6.1.2, p1 (the Effects clause of the <code>money_get</code>
-facet's <code>do_get</code> member functions) also specifies that
-<code><i>err</i></code>'s initial value be used to compute the final
-value by ORing it with either <code>ios_base::failbit</code> or
-with<code>ios_base::eofbit | ios_base::failbit</code>.
-
- </p>
-
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-We believe the intent is for all facet member functions that take an
-<code>ios_base::iostate&amp;</code> argument to:
-
- </p>
- <ul>
- <li>
-
-ignore the initial value of the <code><i>err</i></code> argument,
-
- </li>
- <li>
-
-reset <code><i>err</i></code> to <code>ios_base::goodbit</code> prior
-to any further processing,
-
- </li>
- <li>
-
-and set either <code>ios_base::eofbit</code>, or
-<code>ios_base::failbit</code>, or both in <code><i>err</i></code>, as
-appropriate, in response to reaching the end-of-file or on parse
-error, or both.
-
- </li>
- </ul>
- <p>
-
-To that effect we propose to change 22.2, p2 as follows:
-
- </p>
- <p>
-
-The <i>put</i><del>()</del> members make no provision for error
-reporting. (Any failures of the OutputIterator argument must be
-extracted from the returned iterator.) <ins>Unless otherwise
-specified, </ins>the <i>get</i><del>()</del> members <ins>that</ins>
-take an <code>ios_base::iostate&amp;</code> argument <del>whose value
-they ignore, but set to ios_base::failbit in case of a parse
-error.</del><ins>, <code><i>err</i></code>, start by evaluating
-<code>err = ios_base::goodbit</code>, and may subsequently set
-<i>err</i> to either <code>ios_base::eofbit</code>, or
-<code>ios_base::failbit</code>, or <code>ios_base::eofbit |
-ios_base::failbit</code> in response to reaching the end-of-file or in
-case of a parse error, or both, respectively.</ins>
-
- </p>
-
-
-<p><i>[
-Kona (2007): We need to change the proposed wording to clarify that the
-phrase "the get members" actually denotes <tt>get()</tt>, <tt>get_date()</tt>, etc.
-Proposed Disposition: Open
-]</i></p>
-
-
-
-
-<hr>
-<h3><a name="588"></a>588. requirements on zero sized tr1::arrays and other details</h3>
-<p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2006-07-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The wording used for section 23.2.1 [lib.array] seems to be subtly
-ambiguous about zero sized arrays (N==0). Specifically:
-</p>
-<p>
-* "An instance of array&lt;T, N&gt; stores N elements of type T, so that
-[...]"
-</p>
-<p>
-Does this imply that a zero sized array object stores 0 elements, i.e.
-that it cannot store any element of type T? The next point clarifies
-the rationale behind this question, basically how to implement begin()
-and end():
-</p>
-<p>
-* 23.2.1.5 [lib.array.zero], p2: "In the case that N == 0, begin() ==
-end() == unique value."
-</p>
-<p>
-What does "unique" mean in this context? Let's consider the following
-possible implementations, all relying on a partial specialization:
-</p>
-<blockquote><pre>a)
- template&lt; typename T &gt;
- class array&lt; T, 0 &gt; {
-
- ....
-
- iterator begin()
- { return iterator( reinterpret_cast&lt; T * &gt;( this ) ); }
- ....
-
- };
-</pre></blockquote>
-<p>
-This has been used in boost, probably intending that the return value
-had to be unique to the specific array object and that array couldn't
-store any T. Note that, besides relying on a reinterpret_cast, has
-(more than potential) alignment problems.
-</p>
-<blockquote><pre>b)
- template&lt; typename T &gt;
- class array&lt; T, 0 &gt; {
-
- T t;
-
- iterator begin()
- { return iterator( &amp;t ); }
- ....
-
- };
-</pre></blockquote>
-<p>
-This provides a value which is unique to the object and to the type of
-the array, but requires storing a T. Also, it would allow the user to
-mistakenly provide an initializer list with one element.
-</p>
-<p>
-A slight variant could be returning *the* null pointer of type T
-</p>
-<blockquote><pre> return static_cast&lt;T*&gt;(0);
-</pre></blockquote>
-<p>
-In this case the value would be unique to the type array&lt;T, 0&gt; but not
-to the objects (all objects of type array&lt;T, 0&gt; with the same value
-for T would yield the same pointer value).
-</p>
-<p>
-Furthermore this is inconsistent with what the standard requires from
-allocation functions (see library issue 9).
-</p>
-<p>
-c) same as above but with t being a static data member; again, the
-value would be unique to the type, not to the object.
-</p>
-<p>
-d) to avoid storing a T *directly* while disallowing the possibility
-to use a one-element initializer list a non-aggregate nested class
-could be defined
-</p>
-<blockquote><pre> struct holder { holder() {} T t; } h;
-</pre></blockquote>
-<p>
-and then begin be defined as
-</p>
-<blockquote><pre> iterator begin() { return &amp;h.t; }
-</pre></blockquote>
-<p>
-But then, it's arguable whether the array stores a T or not.
-Indirectly it does.
-</p>
-<p>
------------------------------------------------------
-</p>
-<p>
-Now, on different issues:
-</p>
-<p>
-* what's the effect of calling assign(T&amp;) on a zero-sized array? There
-seems to be only mention of front() and back(), in 23.2.1 [lib.array]
-p4 (I would also suggest to move that bullet to section 23.2.1.5
-[lib.array.zero], for locality of reference)
-</p>
-<p>
-* (minor) the opening paragraph of 23.2.1 [lib.array] wording is a bit
-inconsistent with that of other sequences: that's not a problem in
-itself, but compare it for instance with "A vector is a kind of
-sequence that supports random access iterators"; though the intent is
-obvious one might argue that the wording used for arrays doesn't tell
-what an array is, and relies on the reader to infer that it is what
-the &lt;array&gt; header defines.
-</p>
-<p>
-* it would be desiderable to have a static const data member of type
-std::size_t, with value N, for usage as integral constant expression
-</p>
-<p>
-* section 23.1 [lib.container.requirements] seem not to consider
-fixed-size containers at all, as it says: "[containers] control
-allocation and deallocation of these objects [the contained objects]
-through constructors, destructors, *insert and erase* operations"
-</p>
-<p>
-* max_size() isn't specified: the result is obvious but, technically,
-it relies on table 80: "size() of the largest possible container"
-which, again, doesn't seem to consider fixed size containers
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-<p><i>[
-Kona (2007): requirements on zero sized <tt>tr1::array</tt>s and other details
-Issue 617: <tt>std::array</tt> is a sequence that doesn't satisfy the sequence
-requirements? Alisdair will prepare a paper. Proposed Disposition: Open
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="597"></a>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3>
-<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 2006-04-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In a private email, Daveed writes:
-</p>
-<blockquote>
-<p>
-I am not familiar with the C TR, but my guess is that the
-class type approach still won't match a built-in type
-approach because the notion of "promotion" cannot be
-emulated by user-defined types.
-</p>
-<p>
-Here is an example:
-</p>
-</blockquote>
-<pre>
- struct S {
- S(_Decimal32 const&amp;); // Converting constructor
- };
- void f(S);
-
- void f(_Decimal64);
-
- void g(_Decimal32 d) {
- f(d);
- }
-</pre>
-
-<blockquote>
-<p>
-If _Decimal32 is a built-in type, the call f(d) will likely
-resolve to f(_Decimal64) because that requires only a
-promotion, whereas f(S) requires a user-defined conversion.
-</p>
-<p>
-If _Decimal32 is a class type, I think the call f(d) will be
-ambiguous because both the conversion to _Decimal64 and the
-conversion to S will be user-defined conversions with neither
-better than the other.
-</p>
-</blockquote>
-<p>
-Robert comments:
-</p>
-<p>
-In general, a library of arithmetic types cannot exactly emulate the
-behavior of the intrinsic numeric types. There are several ways to tell
-whether an implementation of the decimal types uses compiler
-intrinisics or a library. For example:
-</p>
-<pre> _Decimal32 d1;
- d1.operator+=(5); // If d1 is a builtin type, this won't compile.
-</pre>
-<p>
-In preparing the decimal TR, we have three options:
-</p>
-<ol>
-<li>require that the decimal types be class types</li>
-<li>require that the decimal types be builtin types, like float and double</li>
-<li>specify a library of class types, but allow enough implementor
-latitude that a conforming implementation could instead provide builtin
-types</li>
-</ol>
-<p>
-We decided as a group to pursue option #3, but that approach implies
-that implementations may not agree on the semantics of certain use
-cases (first example, above), or on whether certain other cases are
-well-formed (second example). Another potentially important problem is
-that, under the present definition of POD, the decimal classes are not
-POD types, but builtins will be.
-</p>
-<p>Note that neither example above implies any problems with respect to
-C-to-C++ compatibility, since neither example can be expressed in C.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="606"></a>606. Decimal: allow narrowing conversions</h3>
-<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In c++std-lib-17205, Martin writes:
-</p>
-<blockquote><p>...was it a deliberate design choice to make narrowing
-assignments ill-formed while permitting narrowing compound assignments?
-For instance:
-</p></blockquote>
-<pre> decimal32 d32;
- decimal64 d64;
-
- d32 = 64; // error
- d32 += 64; // okay
-</pre>
-<p>
-In c++std-lib-17229, Robert responds:
-</p>
-<blockquote><p>It is a vestige of an old idea that I forgot to remove
-from the paper. Narrowing assignments should be permitted. The bug is
-that the converting constructors that cause narrowing should not be
-explicit. Thanks for pointing this out.
-</p></blockquote>
-
-<p><b>Proposed resolution:</b></p>
-<p>
-1. In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
-</p>
-<pre> // <i>3.2.2.2 conversion from floating-point type:</i>
- <del>explicit</del> decimal32(decimal64 <i>d64</i>);
- <del>explicit</del> decimal32(decimal128 <i>d128</i>);
-</pre>
-<p>
-2. Do the same thing in "3.2.2.2. Conversion from floating-point type."
-</p>
-<p>
-3. In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
-</p>
-<pre> // <i>3.2.3.2 conversion from floating-point type:</i>
- <del>explicit</del> decimal64(decimal128 <i>d128</i>);
-</pre>
-<p>
-4. Do the same thing in "3.2.3.2. Conversion from floating-point type."
-</p>
-
-<p><i>[
-Redmond: We prefer explicit conversions for narrowing and implicit for widening.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="614"></a>614. std::string allocator requirements still inconsistent</h3>
-<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-This is based on N2134, where 21.3.1/2 states:
-"... The Allocator object used shall be a copy of the Allocator object
-passed to the basic_string object's constructor or, if the constructor does
-not take an Allocator argument, a copy of a default-constructed Allocator
-object."
-</p>
-<p>
-Section 21.3.2/1 lists two constructors:
-</p>
-<blockquote><pre>basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str );
-
-basic_string(const basic_string&lt;charT,traits,Allocator&gt;&amp; str ,
- size_type pos , size_type n = npos,
- const Allocator&amp; a = Allocator());
-</pre></blockquote>
-<p>
-and then says "In the first form, the Allocator value used is copied from
-str.get_allocator().", which isn't an option according to 21.3.1.
-</p>
-<p><i>[
-Batavia: We need blanket statement to the effect of:
-]</i></p>
-
-
-<ol>
-<li>If an allocator is passed in, use it, or,</li>
-<li>If a string is passed in, use its allocator.</li>
-</ol>
-<p><i>[
-Review constructors and functions that return a string; make sure we follow these
-rules (substr, operator+, etc.). Howard to supply wording.
-]</i></p>
-
-
-<p><i>[
-Bo adds: The new container constructor which takes only a <tt>size_type</tt> is not
-consistent with 23.1 [container.requirements], p9 which says in part:
-
-<blockquote>
-All other constructors for these container types take an
-<tt>Allocator&amp;</tt> argument (20.1.2), an allocator whose value type
-is the same as the container's value type. A copy of this argument is
-used for any memory allocation performed, by these constructors and by
-all member functions, during the lifetime of each container object.
-</blockquote>
-]</i></p>
-
-
-<p><i>[
-post Bellevue: We re-confirm that the issue is real. Pablo will provide wording.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="617"></a>617. std::array is a sequence that doesn't satisfy the sequence requirements?</h3>
-<p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-30</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The <tt>&lt;array&gt;</tt> header is given under 23.2 [sequences].
-23.2.1 [array]/paragraph 3 says:
-</p>
-<blockquote><p>
-"Unless otherwise specified, all array operations are as described in
-23.1 [container.requirements]".
-</p></blockquote>
-<p>
-However, array isn't mentioned at all in section 23.1 [container.requirements].
-In particular, Table 82 "Sequence requirements" lists several operations (insert, erase, clear)
-that std::array does not have in 23.2.1 [array].
-</p>
-<p>
-Also, Table 83 "Optional sequence operations" lists several operations that
-std::array does have, but array isn't mentioned.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="629"></a>629. complex<t> insertion and locale dependence</t></h3>
-<p><b>Section:</b> 26.3.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-is there an issue opened for (0,3) as complex number with
-the French local? With the English local, the above parses as an
-imaginery complex number. With the French locale it parses as a
-real complex number.
-</p>
-
-<p>
-Further notes/ideas from the lib-reflector, messages 17982-17984:
-</p>
-
-<blockquote>
-<p>
-Add additional entries in num_punct to cover the complex separator (French would be ';').
-</p>
-<p>
-Insert a space before the comma, which should eliminate the ambiguity.
-</p>
-<p>
-Solve the problem for ordered sequences in general, perhaps with a
-dedicated facet. Then complex should use that solution.
-</p>
-</blockquote>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-After much discussion, we agreed on the following: Add a footnote:
-</p>
-<p>
-[In a locale in which comma is being used as a decimal point character,
-inserting "showbase" into the output stream forces all outputs to show
-an explicit decimal point character; then all inserted complex sequences
-will extract unambiguously.]
-</p>
-<p>
-And move this to READY status.
-</p>
-</blockquote>
-
-<p><i>[
-Pre-Sophia Antipolis, Howard adds:
-]</i></p>
-
-
-<blockquote>
-Changed "showbase" to "showpoint" and changed from Ready to Review.
-</blockquote>
-
-<p><i>[
-Post-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-I neglected to pull this issue from the formal motions page after the "showbase" to "showpoint" change.
-In Sophia Antipolis this change was reviewed by the LWG and the issue was set to Ready. We subsequently
-voted the footnote into the WP with "showbase".
-</p>
-<p>
-I'm changing from WP back to Ready to pick up the "showbase" to "showpoint" change.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a footnote to 26.3.6 [complex.ops] p16:
-</p>
-
-<blockquote>
-[In a locale in which comma is being used as a decimal point character,
-inserting <tt>showpoint</tt> into the output stream forces all outputs to show
-an explicit decimal point character; then all inserted complex sequences
-will extract unambiguously.]
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="630"></a>630. arrays of valarray</h3>
-<p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-Section 26.1 [numeric.requirements], p1 suggests that a
-<code>valarray</code> specialization on a type <code>T</code> that
-satisfies the requirements enumerated in the paragraph is itself a
-valid type on which <code>valarray</code> may be instantiated
-(Footnote 269 makes this clear). I.e.,
-<code>valarray&lt;valarray&lt;T&gt; &gt;</code> is valid as long as
-<code>T</code> is valid. However, since implementations of
-<code>valarray</code> are permitted to initialize storage allocated by
-the class by invoking the default ctor of <code>T</code> followed by
-the copy assignment operator, such implementations of
-<code>valarray</code> wouldn't work with (perhaps user-defined)
-specializations of <code>valarray</code> whose assignment operator had
-undefined behavior when the size of its argument didn't match the size
-of <code>*this</code>. By <i>"wouldn't work"</i> I mean that it would
-be impossible to resize such an array of arrays by calling the
-<code>resize()</code> member function on it if the function used the
-copy assignment operator after constructing all elements using the
-default ctor (e.g., by invoking <code>new value_type[N]</code>) to
-obtain default-initialized storage) as it's permitted to do.
-
- </p>
- <p>
-
-Stated more generally, the problem is that
-<code>valarray&lt;valarray&lt;T&gt; &gt;::resize(size_t)</code> isn't
-required or guaranteed to have well-defined semantics for every type
-<code>T</code> that satisfies all requirements in
-26.1 [numeric.requirements].
-
- </p>
- <p>
-
-I believe this problem was introduced by the adoption of the
-resolution outlined in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0857.asc">N0857</a>,
-<i>Assignment of valarrays</i>, from 1996. The copy assignment
-operator of the original numerical array classes proposed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0280.pdf">N0280</a>,
-as well as the one proposed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>
-(both from 1993), had well-defined semantics for arrays of unequal
-size (the latter explicitly only when <code>*this</code> was empty;
-assignment of non empty arrays of unequal size was a runtime error).
-
- </p>
- <p>
-
-The justification for the change given in N0857 was the "loss of
-performance [deemed] only significant for very simple operations on
-small arrays or for architectures with very few registers."
-
- </p>
- <p>
-
-Since tiny arrays on a limited subset of hardware architectures are
-likely to be an exceedingly rare case (despite the continued
-popularity of x86) I propose to revert the resolution and make the
-behavior of all <code>valarray</code> assignment operators
-well-defined even for non-conformal arrays (i.e., arrays of unequal
-size). I have implemented this change and measured no significant
-degradation in performance in the common case (non-empty arrays of
-equal size). I have measured a 50% (and in some cases even greater)
-speedup in the case of assignments to empty arrays versus calling
-<code>resize()</code> first followed by an invocation of the copy
-assignment operator.
-
- </p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-If no proposed wording by June meeting, this issue should be closed NAD.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-Change 26.5.2.2 [valarray.assign], p1 as follows:
-
- </p>
- <blockquote>
- <p>
- <code>
-
-valarray&lt;T&gt;&amp; operator=(const valarray&lt;T&gt;&amp;<ins> x</ins>);
-
- </code>
- </p>
- <p>
-
--1- Each element of the <code>*this</code> array is assigned the value
-of the corresponding element of the argument array. <del>The
-resulting behavior is undefined if </del><ins>When </ins>the length of
-the argument array is not equal to the length of the *this
-array<del>.</del><ins> resizes <code>*this</code> to make the two
-arrays the same length, as if by calling
-<code>resize(x.size())</code>, before performing the assignment.</ins>
-
- </p>
- </blockquote>
- <p>
-
-And add a new paragraph just below paragraph 1 with the following
-text:
-
- </p>
- <blockquote>
- <p>
-
-<ins>-2- <i>Postcondition</i>: <code>size() == x.size()</code>.</ins>
-
- </p>
- </blockquote>
- <p>
-
-Also add the following paragraph to 26.5.2.2 [valarray.assign], immediately after p4:
-
- </p>
- <blockquote>
- <p>
-
-<ins>-?- When the length, <i><code>N</code></i> of the array referred
-to by the argument is not equal to the length of <code>*this</code>,
-the operator resizes <code>*this</code> to make the two arrays the
-same length, as if by calling <code>resize(<i>N</i>)</code>, before
-performing the assignment.</ins>
-
- </p>
- </blockquote>
-
-<p><i>[
-pre-Sophia Antipolis, Martin adds the following compromise wording, but
-prefers the original proposed resolution:
-]</i></p>
-
-
-<p>
-Change 26.5.2.2 [valarray.assign], p1 as follows:
-</p>
-
-<blockquote>
-<p>
- -1- <i>Requires:</i> <tt>size() == 0 || size() == x.size()</tt>.
-</p>
-<p>
- -2- <i>Effects:</i> If <tt>size() == 0</tt> calls <tt>x.resize(x.size())</tt> first.
- Each element of the <tt>*this</tt> array is assigned the value of the
- corresponding element of the argument array.
-</p>
-<p>
- -3- <i>Postcondition:</i> <tt>size() == x.size()</tt>.
-</p>
-</blockquote>
-
-<p>
-Add the following paragraph to 26.5.2.2 [valarray.assign], immediately after
-p4:
-</p>
-
-<blockquote>
-<p>
- -?- When <tt>size() == 0</tt> and the length, <tt>N</tt> of the array referred to by
- the argument is not equal to the length of <tt>*this</tt>, the operator
- resizes <tt>*this</tt> to make the two arrays the same length, as if by
- calling <tt>resize(N)</tt>, before performing the assignment. Otherwise,
- when <tt>size() &gt; 0</tt> and <tt>size() != N</tt>, the behavior is undefined.
-</p>
-</blockquote>
-
-
-
-<p><i>[
-Kona (2007): Gaby to propose wording for an alternative resolution in
-which you can assign to a <tt>valarray</tt> of size 0, but not to any other
-<tt>valarray</tt> whose size is unequal to the right hand side of the assignment.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="631"></a>631. conflicting requirements for <tt>BinaryPredicate</tt></h3>
-<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> James Kanze <b>Date:</b> 2007-01-31</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The general requirements for <tt><tt>BinaryPredicate</tt></tt> (in 25 [algorithms]/8) contradict the implied specific requirements for
-some functions. In particular, it says that:
-</p>
-
-<blockquote><p>
-[...] if an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt>
-as its argument and <tt><i>first1</i></tt> and <i>first2</i> as its
-iterator arguments, it should work correctly in the construct <tt>if
-(binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt>.
-<tt>BinaryPredicate</tt> always takes the first iterator type as its
-first argument, that is, in those cases when <tt>T <i>value</i></tt> is
-part of the signature, it should work correctly in the context of <tt>if
-(binary_pred (*<i>first1</i> , <i>value</i>)){...}</tt>.
-</p></blockquote>
-
-<p>
-In the description of <tt>upper_bound</tt> (25.3.3.2 [upper.bound]/2), however, the use is described as
-"<tt>!comp(<i>value</i>, <i>e</i>)</tt>", where <tt><i>e</i></tt> is an
-element of the sequence (a result of dereferencing
-<tt>*<i>first</i></tt>).
-</p>
-
-<p>
-In the description of <tt>lexicographical_compare</tt>, we have both
-"<tt>*<i>first1</i> &lt; *<i>first2</i></tt>" and "<tt>*<i>first2</i>
-&lt; *<i>first1</i></tt>" (which presumably implies "<tt>comp(
-*<i>first1</i>, *<i>first2</i> )</tt>" and "<tt>comp( *<i>first2</i>,
-*<i>first1</i> )</tt>".
-</p>
-
-<p><i>[
-Toronto: Moved to Open. ConceptGCC seems to get <tt>lower_bound</tt>
-and <tt>upper_bound</tt> to work withoutt these changes.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Logically, the <tt>BinaryPredicate</tt> is used as an ordering
-relationship, with the semantics of "less than". Depending on the
-function, it may be used to determine equality, or any of the inequality
-relationships; doing this requires being able to use it with either
-parameter first. I would thus suggest that the requirement be:
-</p>
-
-<blockquote><p>
-[...] <tt>BinaryPredicate</tt> always takes the first iterator
-<tt>value_type</tt> as one of its arguments, it is unspecified which. If
-an algorithm takes <tt>BinaryPredicate <i>binary_pred</i></tt> as its
-argument and <tt><i><i>first1</i></i></tt> and <i>first2</i> as its
-iterator arguments, it should work correctly both in the construct
-<tt>if (binary_pred (*<i>first1</i> , *<i>first2</i> )){...}</tt> and
-<tt>if (binary_pred (*<i>first2</i>, *<i>first1</i>)){...}</tt>. In
-those cases when <tt>T <i>value</i></tt> is part of the signature, it
-should work correctly in the context of <tt>if (binary_pred
-(*<i>first1</i> , <i>value</i>)){...}</tt> and of <tt>if (binary_pred
-(<i>value</i>, *<i>first1</i>)){...}</tt>. [<i>Note:</i> if the two
-types are not identical, and neither is convertable to the other, this
-may require that the <tt>BinaryPredicate</tt> be a functional object
-with two overloaded <tt>operator()()</tt> functions. <i>--end note</i>]
-</p></blockquote>
-
-<p>
-Alternatively, one could specify an order for each function. IMHO, this
-would be more work for the committee, more work for the implementors,
-and of no real advantage for the user: some functions, such as
-<tt>lexicographical_compare</tt> or <tt>equal_range</tt>, will still require both
-functions, and it seems like a much easier rule to teach that both
-functions are always required, rather than to have a complicated list of
-when you only need one, and which one.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="632"></a>632. Time complexity of size() for std::set</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Lionel B <b>Date:</b> 2007-02-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-A recent news group discussion:
-</p>
-<blockquote>
-<p>
-Anyone know if the Standard has anything to say about the time complexity
-of size() for std::set? I need to access a set's size (/not/ to know if it is empty!) heavily
-during an algorithm and was thus wondering whether I'd be better off
-tracking the size "manually" or whether that'd be pointless.
-</p>
-<p>
-That would be pointless. size() is O(1).
-</p>
-<p>
-Nit: the standard says "should" have constant time. Implementations may take
-license to do worse. I know that some do this for <tt>std::list&lt;&gt;</tt> as a part of
-some trade-off with other operation.
-</p>
-
-<p>
-I was aware of that, hence my reluctance to use size() for std::set.
-</p>
-<p>
-However, this reason would not apply to <tt>std::set&lt;&gt;</tt> as far as I can see.
-</p>
-<p>
-Ok, I guess the only option is to try it and see...
-</p>
-</blockquote>
-
-<p>
-If I have any recommendation to the C++ Standards Committee it is that
-implementations must (not "should"!) document clearly[1], where known, the
-time complexity of *all* container access operations.
-</p>
-<p>
-[1] In my case (gcc 4.1.1) I can't swear that the time complexity of size()
-for std::set is not documented... but if it is it's certainly well hidden
-away.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-<p><i>[
-Kona (2007): This issue affects all the containers. We'd love to see a
-paper dealing with the broad issue. We think that the complexity of the
-<tt>size()</tt> member of every container -- except possibly <tt>list</tt> -- should be
-O(1). Alan has volunteered to provide wording.
-]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Mandating O(1) size will not fly, too many implementations would be
-invalidated. Alan to provide wording that toughens wording, but that
-does not absolutely mandate O(1).
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="635"></a>635. domain of <tt>allocator::address</tt></h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-08</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The table of allocator requirements in 20.1.2 [allocator.requirements] describes
-<tt>allocator::address</tt> as:
-</p>
-<blockquote><pre>a.address(r)
-a.address(s)
-</pre></blockquote>
-<p>
-where <tt>r</tt> and <tt>s</tt> are described as:
-</p>
-<blockquote><p>
-a value of type <tt>X::reference</tt> obtained by the expression <tt>*p</tt>.
-</p></blockquote>
-
-<p>
-and <tt>p</tt> is
-</p>
-
-<blockquote><p>
-a value of type <tt>X::pointer</tt>, obtained by calling <tt>a1.allocate</tt>,
-where <tt>a1 == a</tt>
-</p></blockquote>
-
-<p>
-This all implies that to get the address of some value of type <tt>T</tt> that
-value must have been allocated by this allocator or a copy of it.
-</p>
-
-<p>
-However sometimes container code needs to compare the address of an external value of
-type <tt>T</tt> with an internal value. For example <tt>list::remove(const T&amp; t)</tt>
-may want to compare the address of the external value <tt>t</tt> with that of a value
-stored within the list. Similarly <tt>vector</tt> or <tt>deque insert</tt> may
-want to make similar comparisons (to check for self-referencing calls).
-</p>
-
-<p>
-Mandating that <tt>allocator::address</tt> can only be called for values which the
-allocator allocated seems overly restrictive.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.1.2 [allocator.requirements]:
-</p>
-
-<blockquote>
-<p>
-<tt>r</tt> : a value of type <tt>X::reference</tt> <del>obtained by the expression *p</del>.
-</p>
-<p>
-<tt>s</tt> : a value of type <tt>X::const_reference</tt> <del>obtained by the
-expression <tt>*q</tt> or by conversion from a value <tt>r</tt></del>.
-</p>
-</blockquote>
-
-<p><i>[
-post Oxford: This would be rendered NAD Editorial by acceptance of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
-]</i></p>
-
-
-<p><i>[
-Kona (2007): This issue is section 8 of N2387. There was some discussion of it but
-no resolution to this issue was recorded. Moved to Open.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="644"></a>644. Possible typos in 'function' description</h3>
-<p><b>Section:</b> X [func.wrap.func.undef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-25</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-X [func.wrap.func.undef]
-</p>
-<p>
-The note in paragraph 2 refers to 'undefined void operators', while the
-section declares a pair of operators returning bool.
-</p>
-
-<p><i>[
-Post-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-Changed from Pending WP to Open. This issue was voted to WP at the same time the operators were
-changed from private to deleted. The two issues stepped on each other. What do we want the return
-type of these deleted functions to be?
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.6.15.2 [func.wrap.func]
-</p>
-
-<blockquote><pre>...
-private:
- // X [func.wrap.func.undef], undefined operators:
- template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
- template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
-};
-</pre></blockquote>
-
-<p>
-Change X [func.wrap.func.undef]
-</p>
-
-<blockquote><pre>template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator==(const function&lt;Function2&gt;&amp;);
-template&lt;class Function2&gt; <del>bool</del> <ins>void</ins> operator!=(const function&lt;Function2&gt;&amp;);
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="659"></a>659. istreambuf_iterator should have an operator-&gt;()</h3>
-<p><b>Section:</b> 24.5.3 [istreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-03-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Greg Herlihy has clearly demonstrated that a user defined input
-iterator should have an operator-&gt;(), even if its
-value type is a built-in type (comp.std.c++, "Re: Should any iterator
-have an operator-&gt;() in C++0x?", March 2007). And as Howard
-Hinnant remarked in the same thread that the input iterator
-<tt>istreambuf_iterator</tt> doesn't have one, this must be a
-defect!
-</p>
-<p>
-Based on Greg's example, the following code demonstrates the issue:
-</p><pre> #include &lt;iostream&gt;
- #include &lt;fstream&gt;
- #include &lt;streambuf&gt;
-
- typedef char C;
- int main ()
- {
- std::ifstream s("filename", std::ios::in);
- std::istreambuf_iterator&lt;char&gt; i(s);
-
- (*i).~C(); // This is well-formed...
- i-&gt;~C(); // ... so this should be supported!
- }
-</pre>
-
-<p>
-Of course, operator-&gt; is also needed when the value_type of
-istreambuf_iterator is a class.
-</p>
-<p>
-The operator-&gt; could be implemented in various ways. For instance,
-by storing the current value inside the iterator, and returning its
-address. Or by returning a proxy, like operator_arrow_proxy, from
-<a href="http://www.boost.org/boost/iterator/iterator_facade.hpp">http://www.boost.org/boost/iterator/iterator_facade.hpp</a>
-</p>
-<p>
-I hope that the resolution of this issue will contribute to getting a
-clear and consistent definition of iterator concepts.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to the synopsis in 24.5.3 [istreambuf.iterator]:
-</p>
-
-<blockquote><pre>charT operator*() const;
-<ins>pointer operator-&gt;() const;</ins>
-istreambuf_iterator&lt;charT,traits&gt;&amp; operator++();
-</pre></blockquote>
-
-<p>
-Change 24.5.3 [istreambuf.iterator], p1:
-</p>
-
-<blockquote><p>
-The class template <tt>istreambuf_iterator</tt> reads successive
-characters from the <tt>streambuf</tt> for which it was constructed.
-<tt>operator*</tt> provides access to the current input character, if
-any. <ins><tt>operator-&gt;</tt> may return a proxy.</ins> Each time
-<tt>operator++</tt> is evaluated, the iterator advances to the next
-input character. If the end of stream is reached
-(<tt>streambuf_type::sgetc()</tt> returns <tt>traits::eof()</tt>), the
-iterator becomes equal to the end of stream iterator value. The default
-constructor <tt>istreambuf_iterator()</tt> and the constructor
-<tt>istreambuf_iterator(0)</tt> both construct an end of stream iterator
-object suitable for use as an end-of-range.
-</p></blockquote>
-
-
-
-<p><i>[
-Kona (2007): The proposed resolution is inconsistent because the return
-type of <tt>istreambuf_iterator::operator-&gt;()</tt> is specified to be <tt>pointer</tt>,
-but the proposed text also states that "<tt>operator-&gt;</tt> may return a proxy."
-]</i></p>
-
-
-<p><i>[
-Niels Dekker (mailed to Howard Hinnant):
-]</i></p>
-
-<blockquote>
-<p>
-The proposed resolution does
-not seem inconsistent to me. <tt>istreambuf_iterator::operator-&gt;()</tt> should
-have <tt>istreambuf_iterator::pointer</tt> as return type, and this return type
-may in fact be a proxy.
-</p>
-<p>
-AFAIK, the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445">445</a> ("<tt>iterator_traits::reference</tt>
-unspecified for some iterator categories") implies that for any iterator
-class <tt>Iter</tt>, the return type of <tt>operator-&gt;()</tt> is <tt>Iter::pointer</tt>, by
-definition. I don't think <tt>Iter::pointer</tt> needs to be a raw pointer.
-</p>
-<p>
-Still I wouldn't mind if the text "<tt>operator-&gt;</tt> may return a proxy" would
-be removed from the resolution. I think it's up to the library
-implementation, how to implement <tt>istreambuf_iterator::operator-&gt;()</tt>. As
-longs as it behaves as expected: <tt>i-&gt;m</tt> should have the same effect as
-<tt>(*i).m</tt>. Even for an explicit destructor call, <tt>i-&gt;~C()</tt>. The main issue
-is just: <tt>istreambuf_iterator</tt> should have an <tt>operator-&gt;()</tt>!
-</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="667"></a>667. <tt>money_get</tt>'s widened minus sign</h3>
-<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-22.2.6.1.2 [locale.money.get.virtuals], para 1 says:
-</p>
-
-<blockquote><p>
-The result is returned as an integral value
-stored in <tt>units</tt> or as a sequence of digits possibly preceded by a
-minus sign (as produced by <tt>ct.widen(c)</tt> where <tt>c</tt> is '-' or in the range
-from '0' through '9', inclusive) stored in <tt>digits</tt>.
-</p></blockquote>
-
-<p>
-The following
-objection has been raised:
-</p>
-
-<blockquote><p>
-Some implementations interpret this to mean that a facet derived from
-<tt>ctype&lt;wchar_t&gt;</tt> can provide its own member <tt>do_widen(char)</tt>
-which produces e.g. <tt>L'@'</tt> for the "widened" minus sign, and that the
-<tt>'@'</tt> symbol will appear in the resulting sequence of digits. Other
-implementations have assumed that one or more places in the standard permit the
-implementation to "hard-wire" <tt>L'-'</tt> as the "widened" minus sign. Are
-both interpretations permissible, or only one?
-</p></blockquote>
-
-<p>
-[Plum ref _222612Y14]
-</p>
-
-<p>
-Furthermore: if <tt>ct.widen('9')</tt> produces <tt>L'X'</tt> (a non-digit), does a
-parse fail if a <tt>'9'</tt> appears in the subject string? [Plum ref _22263Y33]
-</p>
-
-<p><i>[
-Kona (2007): Bill and Dietmar to provide proposed wording.
-]</i></p>
-
-
-<p><i>[
-post Bellevue: Bill adds:
-]</i></p>
-
-
-<blockquote>
-The Standard is clear that the minus sign stored in <tt>digits</tt> is <tt>ct.widen('-')</tt>.
-The subject string must contain characters <tt>c</tt> in the set <tt>[-0123456789]</tt>
-which are translated by <tt>ct.widen(c)</tt> calls before being stored in <tt>digits</tt>;
-the widened characters are not relevant to the parsing of the subject string.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="668"></a>668. <tt>money_get</tt>'s empty minus sign</h3>
-<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-22.2.6.1.2 [locale.money.get.virtuals], para 3 says:
-</p>
-
-<blockquote><p>
-If <tt>pos</tt> or <tt>neg</tt> is empty, the sign component is
-optional, and if no sign is detected, the result is given the sign
-that corresponds to the source of the empty string.
-</p></blockquote>
-
-<p>
-The following
-objection has been raised:
-</p>
-
-<blockquote><p>
-A <tt>negative_sign</tt> of "" means "there is no
-way to write a negative sign" not "any null sequence is a negative
-sign, so it's always there when you look for it".
-</p></blockquote>
-
-<p>
-[Plum ref _222612Y32]
-</p>
-
-<p><i>[
-Kona (2007): Bill to provide proposed wording and interpretation of existing wording.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="669"></a>669. Equivalent postive and negative signs in <tt>money_get</tt></h3>
-<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-22.2.6.1.2 [locale.money.get.virtuals], para 3 sentence 4 says:
-</p>
-
-<blockquote><p>
-If the first character of <tt>pos</tt> is equal to the first character of <tt>neg</tt>,
-or if both strings are empty, the result is given a positive sign.
-</p></blockquote>
-
-<p>
-One interpretation is that an input sequence must match either the
-positive pattern or the negative pattern, and then in either event it
-is interpreted as positive. The following objections has been raised:
-</p>
-
-<blockquote><p>
-The input can successfully match only a positive sign, so the negative
-pattern is an unsuccessful match.
-</p></blockquote>
-
-<p>
-[Plum ref _222612Y34, 222612Y51b]
-</p>
-
-<p><i>[
-Bill to provide proposed wording and interpretation of existing wording.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="670"></a>670. <tt>money_base::pattern</tt> and <tt>space</tt></h3>
-<p><b>Section:</b> 22.2.6.3 [locale.moneypunct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a></p>
-<p><b>Discussion:</b></p>
-
-
-<p>
-22.2.6.3 [locale.moneypunct], para 2 says:
-</p>
-
-<blockquote><p>
-The value <tt>space</tt> indicates that at least one space is required at
-that position.
-</p></blockquote>
-
-<p>
-The following objection has been raised:
-</p>
-
-<blockquote><p>
-Whitespace is optional when matching space. (See 22.2.6.1.2 [locale.money.get.virtuals], para 2.)
-</p></blockquote>
-
-<p>
-[Plum ref _22263Y22]
-</p>
-
-<p><i>[
-Kona (2007): Bill to provide proposed wording. We agree that C++03 is
-ambiguous, and that we want C++0X to say "space" means 0 or more
-whitespace characters on input.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="671"></a>671. precision of hexfloat</h3>
-<p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> John Salmon <b>Date:</b> 2007-04-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I am trying to understand how TR1 supports hex float (%a) output.
-</p>
-<p>
-As far as I can tell, it does so via the following:
-</p>
-<p>
-8.15 Additions to header &lt;locale&gt; [tr.c99.locale]
-</p>
-<p>
-In subclause 22.2.2.2.2 [facet.num.put.virtuals], Table 58 Floating-point conversions, after
-the line:
-floatfield == ios_base::scientific %E
-</p>
-<p>
-add the two lines:
-</p>
-<blockquote><pre>floatfield == ios_base::fixed | ios_base::scientific &amp;&amp; !uppercase %a
-floatfield == ios_base::fixed | ios_base::scientific %A 2
-</pre></blockquote>
-<p>
-[Note: The additional requirements on print and scan functions, later
-in this clause, ensure that the print functions generate hexadecimal
-floating-point fields with a %a or %A conversion specifier, and that
-the scan functions match hexadecimal floating-point fields with a %g
-conversion specifier. &nbsp;end note]
-</p>
-<p>
-Following the thread, in 22.2.2.2.2 [facet.num.put.virtuals], we find:
-</p>
-<p>
-For conversion from a floating-point type, if (flags &amp; fixed) != 0 or
-if str.precision() &gt; 0, then str.precision() is specified in the
-conversion specification.
-</p>
-<p>
-This would seem to imply that when floatfield == fixed|scientific, the
-precision of the conversion specifier is to be taken from
-str.precision(). &nbsp;Is this really what's intended? &nbsp;I sincerely hope
-that I'm either missing something or this is an oversight. &nbsp;Please
-tell me that the committee did not intend to mandate that hex floats
-(and doubles) should by default be printed as if by %.6a.
-</p>
-
-<p><i>[
-Howard: I think the fundamental issue we overlooked was that with %f,
-%e, %g, the default precision was always 6. &nbsp;With %a the default
-precision is not 6, it is infinity. &nbsp;So for the first time, we need to
-distinguish between the default value of precision, and the precision
-value 6.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-<p><i>[
-Kona (2007): Robert volunteers to propose wording.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="675"></a>675. Move assignment of containers</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-James Hopkin pointed out to me that if <tt>vector&lt;T&gt;</tt> move assignment is O(1)
-(just a <tt>swap</tt>) then containers such as <tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> might have
-the wrong semantics under move assignment when the source is not truly an rvalue, but a
-moved-from lvalue (destructors could run late).
-</p>
-
-<blockquote><pre><tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v1;
-<tt>vector&lt;shared_ptr&lt;ostream&gt;&gt;</tt> v2;
-...
-v1 = v2; // #1
-v1 = std::move(v2); // #2
-</pre></blockquote>
-
-<p>
-Move semantics means not caring what happens to the source (<tt>v2</tt> in this example).
-It doesn't mean not caring what happens to the target (<tt>v1</tt>). In the above example
-both assignments should have the same effect on <tt>v1</tt>. Any non-shared <tt>ostream</tt>'s
-<tt>v1</tt> owns before the assignment should be closed, whether <tt>v1</tt> is undergoing
-copy assignment or move assignment.
-</p>
-
-<p>
-This implies that the semantics of move assignment of a generic container should be
-<tt>clear, swap</tt> instead of just swap. An alternative which could achieve the same
-effect would be to move assign each element. In either case, the complexity of move
-assignment needs to be relaxed to <tt>O(v1.size())</tt>.
-</p>
-
-<p>
-The performance hit of this change is not nearly as drastic as it sounds.
-In practice, the target of a move assignment has always just been move constructed
-or move assigned <i>from</i>. Therefore under <tt>clear, swap</tt> semantics (in
-this common use case) we are still achieving O(1) complexity.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 23.1 [container.requirements]:
-</p>
-
-<blockquote>
-<table border="1">
-<caption>Table 89: Container requirements</caption>
-<tbody><tr>
-<th>expression</th><th>return type</th><th>operational semantics</th>
-<th>assertion/note pre/post-condition</th><th>complexity</th>
-</tr>
-<tr>
-<td><tt>a = rv;</tt></td><td><tt>X&amp;</tt></td>
-<td>All existing elements of <tt>a</tt> are either move assigned or destructed</td>
-<td><tt>a</tt> shall be equal to the
-value that <tt>rv</tt> had
-before this construction
-</td>
-<td><del>(Note C)</del> <ins>linear</ins></td>
-</tr>
-</tbody></table>
-
-<p>
-Notes: the algorithms <tt>swap()</tt>, <tt>equal()</tt> and
-<tt>lexicographical_compare()</tt> are defined in clause 25. Those
-entries marked "(Note A)" should have constant complexity. Those entries
-marked "(Note B)" have constant complexity unless
-<tt>allocator_propagate_never&lt;X::allocator_type&gt;::value</tt> is
-<tt>true</tt>, in which case they have linear complexity.
-<del>Those entries
-marked "(Note C)" have constant complexity if <tt>a.get_allocator() ==
-rv.get_allocator()</tt> or if either
-<tt>allocator_propagate_on_move_assignment&lt;X::allocator_type&gt;::value</tt>
-is <tt>true</tt> or
-<tt>allocator_propagate_on_copy_assignment&lt;X::allocator_type&gt;::value</tt>
-is <tt>true</tt> and linear complexity otherwise.</del>
-</p>
-</blockquote>
-
-
-
-<p><i>[
-post Bellevue Howard adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-This issue was voted to WP in Bellevue, but accidently got stepped on by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
-which was voted to WP simulataneously. Moving back to Open for the purpose of getting
-the wording right. The intent of this issue and N2525 are not in conflict.
-</p>
-</blockquote>
-
-<p><i>[
-post Sophia Antipolis Howard updated proposed wording:
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="676"></a>676. Moving the unordered containers</h3>
-<p><b>Section:</b> 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Move semantics are missing from the <tt>unordered</tt> containers. The proposed
-resolution below adds move-support consistent with
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html">N1858</a>
-and the current working draft.
-</p>
-
-<p>
-The current proposed resolution simply lists the requirements for each function.
-These might better be hoisted into the requirements table for unordered associative containers.
-Futhermore a mild reorganization of the container requirements could well be in order.
-This defect report is purposefully ignoring these larger issues and just focusing
-on getting the unordered containers "moved".
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Add to 23.4 [unord]:
-</p>
-
-<blockquote><pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-
-...
-
-template &lt;class Value, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
- unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
- unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_set&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
-
-template &lt;class Value, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Value, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_multiset&lt;Value, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
-
-<p><b><tt>unordered_map</tt></b></p>
-
-<p>
-Change 23.4.1 [unord.map]:
-</p>
-
-<blockquote><pre>class unordered_map
-{
- ...
- unordered_map(const unordered_map&amp;);
- <ins>unordered_map(unordered_map&amp;&amp;);</ins>
- ~unordered_map();
- unordered_map&amp; operator=(const unordered_map&amp;);
- <ins>unordered_map&amp; operator=(unordered_map&amp;&amp;);</ins>
- ...
- // modifiers
- <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
- <ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; obj);</ins>
- iterator insert(iterator hint, const value_type&amp; obj);
- <ins>template &lt;class P&gt; iterator insert(iterator hint, P&amp;&amp; obj);</ins>
- const_iterator insert(const_iterator hint, const value_type&amp; obj);
- <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
- ...
- void swap(unordered_map&amp;<ins>&amp;</ins>);
- ...
- mapped_type&amp; operator[](const key_type&amp; k);
- <ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins>
- ...
-};
-
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
-
-<p>
-Add to 23.4.1.1 [unord.map.cnstr]:
-</p>
-
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
- unordered_map(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher&amp; hf = hasher(),
- const key_equal&amp; eql = key_equal(),
- const allocator_type&amp; a = allocator_type());
-</pre>
-
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
-then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
-<tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
-
-<p>
-Add to 23.4.1.2 [unord.map.elem]:
-</p>
-
-<blockquote>
-
-<pre>mapped_type&amp; operator[](const key_type&amp; k);</pre>
-
-<blockquote>
-<p>...</p>
-<p><ins>
-<i>Requires:</i> <tt>key_type</tt> shall be <tt>CopyConstructible</tt>
-and <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
-</ins></p>
-</blockquote>
-
-<pre><ins>mapped_type&amp; operator[](key_type&amp;&amp; k);</ins></pre>
-
-<blockquote>
-<p><ins>
-<i>Effects:</i> If the <tt>unordered_map</tt> does not already contain an
-element whose key is equivalent to <tt>k</tt> , inserts the value
-<tt>std::pair&lt;const key_type, mapped_type&gt;(std::move(k), mapped_type())</tt>.
-</ins></p>
-
-<p><ins>
-<i>Requires:</i> <tt>mapped_type</tt> shall be <tt>DefaultConstructible</tt>.
-</ins></p>
-
-<p><ins>
-<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the
-(unique) element whose key is equivalent to <tt>k</tt>.
-</ins></p>
-
-</blockquote>
-
-</blockquote>
-
-<p>
-Add new section [unord.map.modifiers]:
-</p>
-
-<blockquote>
-<pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; pair&lt;iterator, bool&gt; insert(P&amp;&amp; x);</ins>
-<ins>iterator insert(iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; iterator insert(iterator hint, P&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-
-<blockquote>
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
-requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
-<tt>CopyConstructible</tt>.
-</ins></p>
-
-<p><ins>
-<tt>P</tt> shall be convertible to <tt>value_type</tt>.
- If <tt>P</tt> is instantiated as a reference
-type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
-is considered to be an rvalue as it is converted to <tt>value_type</tt>
-and inserted into the <tt>unordered_map</tt>. Specifically, in such
-cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
-<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
-requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
-mapped_type&gt;</tt>, then <tt>key_type</tt> must be
-<tt>CopyConstructible</tt>).
-</ins></p>
-
-<p><ins>
-The signature taking <tt>InputIterator</tt>
-parameters requires <tt>CopyConstructible</tt> of both
-<tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
-
-</blockquote>
-
-</blockquote>
-
-<p>
-Add to 23.4.1.3 [unord.map.swap]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_map&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre>
-</blockquote>
-
-<p><b><tt>unordered_multimap</tt></b></p>
-
-<p>
-Change 23.4.2 [unord.multimap]:
-</p>
-
-<blockquote><pre>class unordered_multimap
-{
- ...
- unordered_multimap(const unordered_multimap&amp;);
- <ins>unordered_multimap(unordered_multimap&amp;&amp;);</ins>
- ~unordered_multimap();
- unordered_multimap&amp; operator=(const unordered_multimap&amp;);
- <ins>unordered_multimap&amp; operator=(unordered_multimap&amp;&amp;);</ins>
- ...
- // modifiers
- iterator insert(const value_type&amp; obj);
- <ins>template &lt;class P&gt; iterator insert(P&amp;&amp; obj);</ins>
- iterator insert(iterator hint, const value_type&amp; obj);
- <ins>template &lt;class P&gt; iterator insert(iterator hint, P&amp;&amp; obj);</ins>
- const_iterator insert(const_iterator hint, const value_type&amp; obj);
- <ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; obj);</ins>
- ...
- void swap(unordered_multimap&amp;<ins>&amp;</ins>);
- ...
-};
-
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
-
-<p>
-Add to 23.4.2.1 [unord.multimap.cnstr]:
-</p>
-
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
- unordered_multimap(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher&amp; hf = hasher(),
- const key_equal&amp; eql = key_equal(),
- const allocator_type&amp; a = allocator_type());
-</pre>
-
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>pair&lt;key_type, mapped_type&gt;</tt>,
-then both <tt>key_type</tt> and <tt>mapped_type</tt> shall be
-<tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
-
-<p>
-Add new section [unord.multimap.modifiers]:
-</p>
-
-<blockquote>
-<pre><ins>iterator insert(const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; iterator insert(P&amp;&amp; x);</ins>
-<ins>iterator insert(iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; iterator insert(iterator hint, P&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>template &lt;class P&gt; const_iterator insert(const_iterator hint, P&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-
-<blockquote>
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const value_type&amp;</tt> parameter
-requires both the <tt>key_type</tt> and the <tt>mapped_type</tt> to be
-<tt>CopyConstructible</tt>.
-</ins></p>
-
-<p><ins>
-<tt>P</tt> shall be convertible to <tt>value_type</tt>.
- If <tt>P</tt> is instantiated as a reference
-type, then the argument <tt>x</tt> is copied from. Otherwise <tt>x</tt>
-is considered to be an rvalue as it is converted to <tt>value_type</tt>
-and inserted into the <tt>unordered_multimap</tt>. Specifically, in such
-cases <tt>CopyConstructible</tt> is not required of <tt>key_type</tt> or
-<tt>mapped_type</tt> unless the conversion from <tt>P</tt> specifically
-requires it (e.g. if <tt>P</tt> is a <tt>tuple&lt;const key_type,
-mapped_type&gt;</tt>, then <tt>key_type</tt> must be
-<tt>CopyConstructible</tt>).
-</ins></p>
-
-<p><ins>
-The signature taking <tt>InputIterator</tt>
-parameters requires <tt>CopyConstructible</tt> of both
-<tt>key_type</tt> and <tt>mapped_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-<p>
-Add to 23.4.2.2 [unord.multimap.swap]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_multimap&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre>
-</blockquote>
-
-<p><b><tt>unordered_set</tt></b></p>
-
-<p>
-Change 23.4.3 [unord.set]:
-</p>
-
-<blockquote><pre>class unordered_set
-{
- ...
- unordered_set(const unordered_set&amp;);
- <ins>unordered_set(unordered_set&amp;&amp;);</ins>
- ~unordered_set();
- unordered_set&amp; operator=(const unordered_set&amp;);
- <ins>unordered_set&amp; operator=(unordered_set&amp;&amp;);</ins>
- ...
- // modifiers
- <del>std::</del>pair&lt;iterator, bool&gt; insert(const value_type&amp; obj);
- <ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; obj);</ins>
- iterator insert(iterator hint, const value_type&amp; obj);
- <ins>iterator insert(iterator hint, value_type&amp;&amp; obj);</ins>
- const_iterator insert(const_iterator hint, const value_type&amp; obj);
- <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
- ...
- void swap(unordered_set&amp;<ins>&amp;</ins>);
- ...
-};
-
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
-
-<p>
-Add to 23.4.3.1 [unord.set.cnstr]:
-</p>
-
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
- unordered_set(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher&amp; hf = hasher(),
- const key_equal&amp; eql = key_equal(),
- const allocator_type&amp; a = allocator_type());
-</pre>
-
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>value_type</tt>, then the
-<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
-
-<p>
-Add new section [unord.set.modifiers]:
-</p>
-
-<blockquote>
-<pre><ins>pair&lt;iterator, bool&gt; insert(const value_type&amp; x);</ins>
-<ins>pair&lt;iterator, bool&gt; insert(value_type&amp;&amp; x);</ins>
-<ins>iterator insert(iterator hint, const value_type&amp; x);</ins>
-<ins>iterator insert(iterator hint, value_type&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-
-<blockquote>
-
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const
-value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
-be <tt>CopyConstructible</tt>.
-</ins></p>
-
-<p><ins>
-The signature taking <tt>InputIterator</tt> parameters requires
-<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
-
-</blockquote>
-
-</blockquote>
-
-<p>
-Add to 23.4.3.2 [unord.set.swap]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_set&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre>
-</blockquote>
-
-<p><b><tt>unordered_multiset</tt></b></p>
-
-<p>
-Change 23.4.4 [unord.multiset]:
-</p>
-
-<blockquote><pre>class unordered_multiset
-{
- ...
- unordered_multiset(const unordered_multiset&amp;);
- <ins>unordered_multiset(unordered_multiset&amp;&amp;);</ins>
- ~unordered_multiset();
- unordered_multiset&amp; operator=(const unordered_multiset&amp;);
- <ins>unordered_multiset&amp; operator=(unordered_multiset&amp;&amp;);</ins>
- ...
- // modifiers
- iterator insert(const value_type&amp; obj);
- <ins>iterator insert(value_type&amp;&amp; obj);</ins>
- iterator insert(iterator hint, const value_type&amp; obj);
- <ins>iterator insert(iterator hint, value_type&amp;&amp; obj);</ins>
- const_iterator insert(const_iterator hint, const value_type&amp; obj);
- <ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; obj);</ins>
- ...
- void swap(unordered_multiset&amp;<ins>&amp;</ins>);
- ...
-};
-
-template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre></blockquote>
-
-<p>
-Add to 23.4.4.1 [unord.multiset.cnstr]:
-</p>
-
-<blockquote>
-<pre>template &lt;class InputIterator&gt;
- unordered_multiset(InputIterator f, InputIterator l,
- size_type n = <i>implementation-defined</i>,
- const hasher&amp; hf = hasher(),
- const key_equal&amp; eql = key_equal(),
- const allocator_type&amp; a = allocator_type());
-</pre>
-
-<blockquote><p>
-<ins>
-<i>Requires:</i> If the iterator's dereference operator returns an
-lvalue or a const rvalue <tt>value_type</tt>, then the
-<tt>value_type</tt> shall be <tt>CopyConstructible</tt>.
-</ins>
-</p></blockquote>
-</blockquote>
-
-<p>
-Add new section [unord.multiset.modifiers]:
-</p>
-
-<blockquote>
-<pre><ins>iterator insert(const value_type&amp; x);</ins>
-<ins>iterator insert(value_type&amp;&amp; x);</ins>
-<ins>iterator insert(iterator hint, const value_type&amp; x);</ins>
-<ins>iterator insert(iterator hint, value_type&amp;&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, const value_type&amp; x);</ins>
-<ins>const_iterator insert(const_iterator hint, value_type&amp;&amp; x);</ins>
-<ins>template &lt;class InputIterator&gt;
- void insert(InputIterator first, InputIterator last);</ins>
-</pre>
-
-<blockquote>
-
-<p><ins>
-<i>Requires:</i> Those signatures taking a <tt>const
-value_type&amp;</tt> parameter requires the <tt>value_type</tt> to
-be <tt>CopyConstructible</tt>.
-</ins></p>
-
-<p><ins>
-The signature taking <tt>InputIterator</tt> parameters requires
-<tt>CopyConstructible</tt> of <tt>value_type</tt> if the dereferenced
-<tt>InputIterator</tt> returns an lvalue or <tt>const</tt> rvalue
-<tt>value_type</tt>.
-</ins></p>
-
-</blockquote>
-
-</blockquote>
-
-<p>
-Add to 23.4.4.2 [unord.multiset.swap]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; x,
- unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; y);</ins>
-<ins>template &lt;class Key, class T, class Hash, class Pred, class Alloc&gt;
- void swap(unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp;&amp; x,
- unordered_multiset&lt;Key, T, Hash, Pred, Alloc&gt;&amp; y);</ins>
-</pre>
-</blockquote>
-
-
-
-<p><i>[
-Voted to WP in Bellevue.
-]</i></p>
-
-
-<p><i>[
-post Bellevue, Pete notes:
-]</i></p>
-
-
-<blockquote>
-<p>
-Please remind people who are reviewing issues to check that the text
-modifications match the current draft. Issue 676, for example, adds two
-overloads for unordered_map::insert taking a hint. One takes a
-const_iterator and returns a const_iterator, and the other takes an
-iterator and returns an iterator. This was correct at the time the issue
-was written, but was changed in Toronto so there is only one hint
-overload, taking a const_iterator and returning an iterator.
-</p>
-<p>
-This issue is not ready. In addition to the relatively minor signature
-problem I mentioned earlier, it puts requirements in the wrong places.
-Instead of duplicating requirements throughout the template
-specifications, it should put them in the front matter that talks about
-requirements for unordered containers in general. This presentation
-problem is editorial, but I'm not willing to do the extensive rewrite
-that it requires. Please put it back into Open status.
-</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="688"></a>688. reference_wrapper, cref unsafe, allow binding to rvalues</h3>
-<p><b>Section:</b> 20.6.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-A <tt>reference_wrapper</tt> can be constructed from an rvalue, either by using
-the constructor, or via <tt>cref</tt> (and <tt>ref</tt> in some corner cases). This leads
-to a dangling reference being stored into the <tt>reference_wrapper</tt> object.
-Now that we have a mechanism to detect an rvalue, we can fix them to
-disallow this source of undefined behavior.
-</p>
-
-<p>
-Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.6 [function.objects], add the following two signatures to the synopsis:
-</p>
-
-<blockquote><pre>template &lt;class T&gt; void ref(const T&amp;&amp; t) = delete;
-template &lt;class T&gt; void cref(const T&amp;&amp; t) = delete;
-</pre></blockquote>
-
-
-
-<p><i>[
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
-addresses the first part of the resolution but not the second.
-]</i></p>
-
-
-<p><i>[
-Bellevue: Doug noticed problems with the current wording.
-]</i></p>
-
-
-<p><i>[
-post Bellevue: Howard and Peter provided revised wording.
-]</i></p>
-
-
-<p><i>[
-This resolution depends on a "favorable" resolution of CWG 606: that is,
-the "special deduction rule" is disabled with the const T&amp;&amp; pattern.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="691"></a>691. const_local_iterator cbegin, cend missing from TR1</h3>
-<p><b>Section:</b> 23.4 [unord], TR1 6.3 [tr.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Joaqun M Lpez Muoz <b>Date:</b> 2007-06-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The last version of TR1 does not include the following member
-functions
-for unordered containers:
-</p>
-
-<blockquote><pre>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;
-</pre></blockquote>
-
-<p>
-which looks like an oversight to me. I've checked th TR1 issues lists
-and the latest working draft of the C++0x std (N2284) and haven't
-found any mention to these menfuns or to their absence.
-</p>
-<p>
-Is this really an oversight, or am I missing something?
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following two rows to table 93 (unordered associative container
-requirements) in section 23.1.5 [unord.req]:
-</p>
-
-<blockquote>
-<table border="1">
-<caption>Unordered associative container requirements (in addition to container)</caption>
-<tbody><tr>
-<th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
-</tr>
-<tr>
-<td><ins><tt>b.cbegin(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>. Note: <tt>[b.cbegin(n), b.cend(n))</tt> is a valid range containing all of the elements in the <tt>n</tt><sup><i>th</i></sup> bucket.</ins></td> <td><ins>Constant</ins></td>
-</tr>
-<tr>
-<td><ins><tt>b.cend(n)</tt></ins></td> <td><ins><tt>const_local_iterator</tt></ins></td> <td><ins><tt>n</tt> shall be in the range <tt>[0, bucket_count())</tt>.</ins></td> <td><ins>Constant</ins></td>
-</tr>
-</tbody></table>
-</blockquote>
-
-<p>
-Add to the synopsis in 23.4.1 [unord.map]:
-</p>
-
-<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;</ins>
-</pre></blockquote>
-
-<p>
-Add to the synopsis in 23.4.2 [unord.multimap]:
-</p>
-
-<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;</ins>
-</pre></blockquote>
-
-<p>
-Add to the synopsis in 23.4.3 [unord.set]:
-</p>
-
-<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;</ins>
-</pre></blockquote>
-
-<p>
-Add to the synopsis in 23.4.4 [unord.multiset]:
-</p>
-
-<blockquote><pre><ins>const_local_iterator cbegin(size_type n) const;
-const_local_iterator cend(size_type n) const;</ins>
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="692"></a>692. <code>get_money</code> and <code>put_money</code> should be formatted I/O functions</h3>
-<p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In a private email Bill Plauger notes:
-</p>
-<blockquote><p>
-I believe that the function that implements <code>get_money</code>
-[from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2072.html">N2072</a>]
-should behave as a formatted input function, and the function that
-implements <code>put_money</code> should behave as a formatted output
-function. This has implications regarding the skipping of whitespace
-and the handling of errors, among other things.
-</p>
-<p>
-The words don't say that right now and I'm far from convinced that
-such a change is editorial.
-</p></blockquote>
-<p>
-Martin's response:
-</p>
-<blockquote><p>
-I agree that the manipulators should handle exceptions the same way as
-formatted I/O functions do. The text in N2072 assumes so but the
-<i>Returns</i> clause explicitly omits exception handling for the sake
-of brevity. The spec should be clarified to that effect.
-</p>
-<p>
-As for dealing with whitespace, I also agree it would make sense for
-the extractors and inserters involving the new manipulators to treat
-it the same way as formatted I/O.
-</p></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a new paragraph immediately above p4 of 27.6.4 [ext.manip] with the
-following text:
-</p>
-<blockquote><p>
-<i>Effects</i>: The expression <code><i>in</i> &gt;&gt; get_money(mon, intl)</code>
-described below behaves as a formatted input function (as
-described in 27.6.1.2.1 [istream.formatted.reqmts]).
-</p></blockquote>
-<p>
-Also change p4 of 27.6.4 [ext.manip] as follows:
-</p>
-<blockquote><p>
-<i>Returns</i>: An object <code>s</code> of unspecified type such that
-if <code>in</code> is an object of type <code>basic_istream&lt;charT,
-traits&gt;</code> then the expression <code><i>in</i> &gt;&gt; get_money(mon, intl)</code> behaves as <ins>a formatted input function
-that calls </ins><code>f(in, mon, intl)</code><del> were
-called</del>. The function <code>f</code> can be defined as...
-</p></blockquote>
-
-
-<p><i>[
-post Bellevue:
-]</i></p>
-
-
-<blockquote>
-We recommend moving immediately to Review. We've looked at the issue and
-have a consensus that the proposed resolution is correct, but want an
-iostream expert to sign off. Alisdair has taken the action item to putt
-this up on the reflector for possible movement by Howard to Tenatively
-Ready.
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="696"></a>696. <code>istream::operator&gt;&gt;(int&amp;)</code> broken</h3>
-<p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-From message c++std-lib-17897:
-</p>
-<p>
-The code shown in 27.6.1.2.2 [istream.formatted.arithmetic] as the "as if"
-implementation of the two arithmetic extractors that don't have a
-corresponding <code>num_get</code> interface (i.e., the
-<code>short</code> and <code>int</code> overloads) is subtly buggy in
-how it deals with <code>EOF</code>, overflow, and other similar
-conditions (in addition to containing a few typos).
-</p>
-<p>
-One problem is that if <code>num_get::get()</code> reaches the EOF
-after reading in an otherwise valid value that exceeds the limits of
-the narrower type (but not <code>LONG_MIN</code> or
-<code>LONG_MAX</code>), it will set <code><i>err</i></code> to
-<code>eofbit</code>. Because of the if condition testing for
-<code>(<i>err</i> == 0)</code>, the extractor won't set
-<code>failbit</code> (and presumably, return a bogus value to the
-caller).
-</p>
-<p>
-Another problem with the code is that it never actually sets the
-argument to the extracted value. It can't happen after the call to
-<code>setstate()</code> since the function may throw, so we need to
-show when and how it's done (we can't just punt as say: "it happens
-afterwards"). However, it turns out that showing how it's done isn't
-quite so easy since the argument is normally left unchanged by the
-facet on error except when the error is due to a misplaced thousands
-separator, which causes <code>failbit</code> to be set but doesn't
-prevent the facet from storing the value.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="698"></a>698. <tt>system_error</tt> needs <tt>const char*</tt> constructors</h3>
-<p><b>Section:</b> 19.4.5.1 [syserr.syserr.overview] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-06-24</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 19.4.5.1 [syserr.syserr.overview] we have the class definition of
-<tt>std::system_error</tt>. In contrast to all exception classes, which
-are constructible with a <tt>what_arg string</tt> (see 19.1 [std.exceptions],
-or <tt>ios_base::failure</tt> in 27.4.2.1.1 [ios::failure]), only overloads with with
-<tt>const string&amp;</tt> are possible. For consistency with the re-designed
-remaining exception classes this class should also provide
-c'tors which accept a const <tt>char* what_arg</tt> string.
-</p>
-<p>
-Please note that this proposed addition makes sense even
-considering the given implementation hint for <tt>what()</tt>, because
-<tt>what_arg</tt> is required to be set as <tt>what_arg</tt> of the base class
-<tt>runtime_error</tt>, which now has the additional c'tor overload
-accepting a <tt>const char*</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-This proposed wording assumes issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a> has been accepted and applied to the working paper.
-</p>
-
-<p>
-Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview, as indicated:
-</p>
-
-<blockquote><pre>public:
- system_error(error_code ec, const string&amp; what_arg);
- <ins>system_error(error_code ec, const char* what_arg);</ins>
- system_error(error_code ec);
- system_error(int ev, const error_category* ecat,
- const string&amp; what_arg);
- <ins>system_error(int ev, const error_category* ecat,
- const char* what_arg);</ins>
- system_error(int ev, const error_category* ecat);
-</pre></blockquote>
-
-<p>
-To 19.4.5.2 [syserr.syserr.members] Class system_error members add:
-</p>
-
-<blockquote>
-<pre>system_error(error_code ec, const char* what_arg);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>code() == ec</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
-</p>
-</blockquote>
-
-<pre>system_error(int ev, const error_category* ecat, const char* what_arg);
-</pre>
-
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>strcmp(runtime_error::what(), what_arg) == 0</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="701"></a>701. assoc laguerre poly's</h3>
-<p><b>Section:</b> TR1 5.2.1.1 [tr.num.sf.Lnm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I see that the definition the associated Laguerre
-polynomials TR1 5.2.1.1 [tr.num.sf.Lnm] has been corrected since
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1687.pdf">N1687</a>.
-However, the draft standard only specifies ranks of integer value <tt>m</tt>,
-while the associated Laguerre polynomials are actually valid for real
-values of <tt>m &gt; -1</tt>. In the case of non-integer values of <tt>m</tt>, the
-definition <tt><i>L</i><sub>n</sub><sup>(m)</sup> = (1/n!)e<sup>x</sup>x<sup>-m</sup> (d/dx)<sup>n</sup> (e<sup>-x</sup>x<sup>m+n</sup>)</tt>
-must be used, which also holds for integer values of <tt>m</tt>. See
-Abramowitz &amp; Stegun, 22.11.6 for the general case, and 22.5.16-17 for
-the integer case. In fact fractional values are most commonly used in
-physics, for example to <tt>m = +/- 1/2</tt> to describe the harmonic
-oscillator in 1 dimension, and <tt>1/2, 3/2, 5/2, ...</tt> in 3
-dimensions.
-</p>
-<p>
-If I am correct, the calculation of the more general case is no
-more difficult, and is in fact the function implemented in the GNU
-Scientific Library. I would urge you to consider upgrading the
-standard, either adding extra functions for real <tt>m</tt> or switching the
-current ones to <tt>double</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="702"></a>702. Restriction in associated Legendre functions</h3>
-<p><b>Section:</b> TR1 5.2.1.2 [tr.num.sf.Plm] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Christopher Crawford <b>Date:</b> 2007-06-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-One other small thing, in TR1 5.2.1.2 [tr.num.sf.Plm], the restriction should be
-<tt>|x| &lt;= 1</tt>, not <tt>x &gt;= 0</tt>.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="704"></a>704. MoveAssignable requirement for container value type overly strict</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The move-related changes inadvertently overwrote the intent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a> removed the requirement of <tt>CopyAssignable</tt> from
-most of the member functions of node-based containers. But the move-related changes
-unnecessarily introduced the <tt>MoveAssignable</tt> requirement for those members which used to
-require <tt>CopyAssignable</tt>.
-</p>
-
-<p>
-We also discussed (c++std-lib-18722) the possibility of dropping <tt>MoveAssignable</tt>
-from some of the sequence requirements. Additionally the <i>in-place</i> construction
-work may further reduce requirements. For purposes of an easy reference, here are the
-minimum sequence requirements as I currently understand them. Those items in requirements
-table in the working draft which do not appear below have been purposefully omitted for
-brevity as they do not have any requirements of this nature. Some items which do not
-have any requirements of this nature are included below just to confirm that they were
-not omitted by mistake.
-</p>
-
-<table border="1">
-<caption>Container Requirements</caption>
-<tbody><tr><td><tt>X u(a)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
-<tr><td><tt>X u(rv)</tt></td><td><tt>array</tt> and containers with a <tt>propagate_never</tt> allocator require <tt>value_type</tt> to be <tt>MoveConstructible</tt></td></tr>
-<tr><td><tt>a = u</tt></td><td>Sequences require <tt>value_type</tt> to be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
- Associative containers require <tt>value_type</tt> to be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a = rv</tt></td><td><tt>array</tt> requires <tt>value_type</tt> to be <tt>MoveAssignable</tt>.
- Sequences and Associative containers with <tt>propagate_never</tt> and <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>swap(a,u)</tt></td><td><tt>array</tt> and containers with <tt>propagate_never</tt> and
- <tt>propagate_on_copy_construction</tt> allocators require <tt>value_type</tt> to be <tt>Swappable</tt>.</td></tr>
-</tbody></table>
-
-<p>
-</p>
-
-<table border="1">
-<caption>Sequence Requirements</caption>
-<tbody><tr><td><tt>X(n)</tt></td><td><tt>value_type</tt> must be <tt>DefaultConstructible</tt></td></tr>
-<tr><td><tt>X(n, t)</tt></td><td><tt>value_type</tt> must be <tt>CopyConstructible</tt></td></tr>
-<tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
-<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
- The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.insert(p, n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt>.</td></tr>
-<tr><td><tt>a.insert(p, i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>CopyAssignable</tt> when the iterators return an lvalue.
- If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.
- The sequences <tt>vector</tt> and <tt>deque</tt> also require the <tt>value_type</tt> to be <tt>MoveAssignable</tt> when the iterators return an rvalue.</td></tr>
-<tr><td><tt>a.erase(p)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.erase(q1, q2)</tt></td><td>The sequences <tt>vector</tt> and <tt>deque</tt> require the <tt>value_type</tt> to be <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.clear()</tt></td><td></td></tr>
-<tr><td><tt>a.assign(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.
- If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.</td></tr>
-<tr><td><tt>a.assign(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>.</td></tr>
-<tr><td><tt>a.resize(n)</tt></td><td>The <tt>value_type</tt> must be <tt>DefaultConstructible</tt>.
- The sequence <tt>vector</tt> also requires the <tt>value_type</tt> to be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.resize(n, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-</tbody></table>
-
-<p>
-</p>
-
-<table border="1">
-<caption>Optional Sequence Requirements</caption>
-<tbody><tr><td><tt>a.front()</tt></td><td></td></tr>
-<tr><td><tt>a.back()</tt></td><td></td></tr>
-<tr><td><tt>a.push_front(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.push_front(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.push_back(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.push_back(rv)</tt></td><td>The <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.pop_front()</tt></td><td></td></tr>
-<tr><td><tt>a.pop_back()</tt></td><td></td></tr>
-<tr><td><tt>a[n]</tt></td><td></td></tr>
-<tr><td><tt>a.at[n]</tt></td><td></td></tr>
-</tbody></table>
-
-<p>
-</p>
-
-<table border="1">
-<caption>Associative Container Requirements</caption>
-<tbody><tr><td><tt>X(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
-</tbody></table>
-
-<p>
-</p>
-
-<table border="1">
-<caption>Unordered Associative Container Requirements</caption>
-<tbody><tr><td><tt>X(i, j, n, hf, eq)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- If the iterators return an rvalue the <tt>value_type</tt> must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_uniq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a_eq.insert(rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, t)</tt></td><td>The <tt>value_type</tt> must be <tt>CopyConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(p, rv)</tt></td><td>The <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>a.insert(i, j)</tt></td><td>If the iterators return an lvalue the <tt>value_type</tt> must be <tt>CopyConstructible</tt>.
- If the iterators return an rvalue the <tt>key_type</tt> and the <tt>mapped_type</tt> (if it exists) must be <tt>MoveConstructible</tt>..</td></tr>
-</tbody></table>
-
-<p>
-</p>
-
-<table border="1">
-<caption>Miscellaneous Requirements</caption>
-<tbody><tr><td><tt>map[lvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>CopyConstructible</tt>.
- The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
-<tr><td><tt>map[rvalue-key]</tt></td><td>The <tt>key_type</tt> must be <tt>MoveConstructible</tt>.
- The <tt>mapped_type</tt> must be <tt>DefaultConstructible</tt> and <tt>MoveConstructible</tt>.</td></tr>
-</tbody></table>
-
-<p><i>[
-Kona (2007): Howard and Alan to update requirements table in issue with emplace signatures.
-]</i></p>
-
-
-<p><i>[
-Bellevue: This should be handled as part of the concepts work.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="708"></a>708. Locales need to be per thread and updated for POSIX changes</h3>
-<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-07-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The POSIX "Extended API Set Part 4,"
-</p>
-<blockquote><p>
-<a href="http://www.opengroup.org/sib/details.tpl?id=C065">http://www.opengroup.org/sib/details.tpl?id=C065</a>
-</p></blockquote>
-<p>
-introduces extensions to the C locale mechanism that
-allow multiple concurrent locales to be used in the same application
-by introducing a type <tt>locale_t</tt> that is very similar to
-<tt>std::locale</tt>, and a number of <tt>_l</tt> functions that make use of it.
-</p>
-<p>
-The global locale (set by setlocale) is now specified to be per-
-process. If a thread does not call <tt>uselocale</tt>, the global locale is
-in effect for that thread. It can install a per-thread locale by
-using <tt>uselocale</tt>.
-</p>
-<p>
-There is also a nice <tt>querylocale</tt> mechanism by which one can obtain
-the name (such as "de_DE") for a specific <tt>facet</tt>, even for combined
-locales, with no <tt>std::locale</tt> equivalent.
-</p>
-<p>
-<tt>std::locale</tt> should be harmonized with the new POSIX <tt>locale_t</tt>
-mechanism and provide equivalents for <tt>uselocale</tt> and <tt>querylocale</tt>.
-</p>
-
-<p><i>[
-Kona (2007): Bill and Nick to provide wording.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="709"></a>709. <tt>char_traits::not_eof</tt> has wrong signature</h3>
-<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The changes made for <tt>constexpr</tt> in 21.1.3 [char.traits.specializations] have
-not only changed the <tt>not_eof</tt> function from pass by const reference to
-pass by value, it has also changed the parameter type from <tt>int_type</tt> to
-<tt>char_type</tt>.
-</p>
-<p>
-This doesn't work for type <tt>char</tt>, and is inconsistent with the
-requirements in Table 56, Traits requirements, 21.1.1 [char.traits.require].
-</p>
-
-<p>
-Pete adds:
-</p>
-
-<blockquote><p>
-For what it's worth, that may not have been an intentional change.
-N2349, which detailed the changes for adding constant expressions to
-the library, has strikeout bars through the <tt>const</tt> and the <tt>&amp;</tt> that
-surround the <tt>char_type</tt> argument, but none through <tt>char_type</tt> itself.
-So the intention may have been just to change to pass by value, with
-text incorrectly copied from the standard.
-</p></blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the signature in 21.1.3.1 [char.traits.specializations.char],
-21.1.3.2 [char.traits.specializations.char16_t], 21.1.3.3 [char.traits.specializations.char32_t],
-and 21.1.3.4 [char.traits.specializations.wchar.t] to
-</p>
-
-<blockquote><pre>static constexpr int_type not_eof(<del>char_type</del> <ins>int_type</ins> c);
-</pre></blockquote>
-
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Resolution: NAD editorial - up to Pete's judgment
-</blockquote>
-
-<p><i>[
-Post Sophia Antipolis
-]</i></p>
-
-
-<blockquote>
-Moved from Pending NAD Editorial to Review. The proposed wording appears to be correct but non-editorial.
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="711"></a>711. Contradiction in empty <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-A discussion on
-<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
-has identified a contradiction in the <tt>shared_ptr</tt> specification.
-The note:
-</p>
-
-<blockquote><p>
-[ <i>Note:</i> this constructor allows creation of an empty shared_ptr instance with a non-NULL stored pointer.
--end note ]
-</p></blockquote>
-
-<p>
-after the aliasing constructor
-</p>
-
-<blockquote><pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
-</pre></blockquote>
-
-<p>
-reflects the intent of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm">N2351</a>
-to, well, allow the creation of an empty <tt>shared_ptr</tt>
-with a non-NULL stored pointer.
-</p>
-
-<p>
-This is contradicted by the second sentence in the Returns clause of 20.7.12.2.5 [util.smartptr.shared.obs]:
-</p>
-
-<blockquote>
-<pre>T* get() const;
-</pre>
-<blockquote><p>
-<i>Returns:</i> the stored pointer. Returns a null pointer if <tt>*this</tt> is empty.
-</p></blockquote>
-</blockquote>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Adopt option 1 and move to review, not ready.
-</p>
-<p>
-There was a lot of confusion about what an empty <tt>shared_ptr</tt> is (the term
-isn't defined anywhere), and whether we have a good mental model for how
-one behaves. We think it might be possible to deduce what the definition
-should be, but the words just aren't there. We need to open an issue on
-the use of this undefined term. (The resolution of that issue might
-affect the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.)
-</p>
-<p>
-The LWG is getting more uncomfortable with the aliasing proposal (N2351)
-now that we realize some of its implications, and we need to keep an eye
-on it, but there isn't support for removing this feature at this time.
-</p>
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-We heard from Peter Dimov, who explained his reason for preferring solution 1.
-</p>
-<p>
-Because it doesn't seem to add anything. It simply makes the behavior
-for p = 0 undefined. For programmers who don't create empty pointers
-with p = 0, there is no difference. Those who do insist on creating them
-presumably have a good reason, and it costs nothing for us to define the
-behavior in this case.
-</p>
-<p>
-The aliasing constructor is sharp enough as it is, so "protecting" users
-doesn't make much sense in this particular case.
-</p>
-<p>
-&gt; Do you have a use case for r being empty and r being non-null?
-</p>
-<p>
-I have received a few requests for it from "performance-conscious"
-people (you should be familiar with this mindset) who don't like the
-overhead of allocating and maintaining a control block when a null
-deleter is used to approximate a raw pointer. It is obviously an "at
-your own risk", low-level feature; essentially a raw pointer behind a
-shared_ptr facade.
-</p>
-<p>
-We could not agree upon a resolution to the issue; some of us thought
-that Peter's description above is supporting an undesirable behavior.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In keeping the N2351 spirit and obviously my preference, change 20.7.12.2.5 [util.smartptr.shared.obs]:
-</p>
-
-<blockquote>
-<pre>T* get() const;
-</pre>
-<blockquote><p>
-<i>Returns:</i> the stored pointer. <del>Returns a null pointer if <tt>*this</tt> is empty.</del>
-</p></blockquote>
-</blockquote>
-
-<p>
-Alternative proposed resolution: (I won't be happy if we do this, but it's possible):
-</p>
-
-<p>
-Change 20.7.12.2.1 [util.smartptr.shared.const]:
-</p>
-
-<blockquote>
-<pre>template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt; const&amp; r, T *p);
-</pre>
-<blockquote>
-<p>
-<ins><i>Requires:</i> If <tt>r</tt> is empty, <tt>p</tt> shall be <tt>0</tt>.</ins>
-</p>
-<p>
-<del>[ <i>Note:</i> this constructor allows creation of an empty <tt>shared_ptr</tt>
-instance with a non-NULL stored pointer.
--- <i>end note</i> ]</del>
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="713"></a>713. <tt>sort()</tt> complexity is too lax</h3>
-<p><b>Section:</b> 25.3.1.1 [sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The complexity of <tt>sort()</tt> is specified as "Approximately <tt>N
-log(N)</tt> (where <tt>N == last - first</tt> ) comparisons on the
-average", with no worst case complicity specified. The intention was to
-allow a median-of-three quicksort implementation, which is usually <tt>O(N
-log N)</tt> but can be quadratic for pathological inputs. However, there is
-no longer any reason to allow implementers the freedom to have a
-worst-cast-quadratic sort algorithm. Implementers who want to use
-quicksort can use a variant like David Musser's "Introsort" (Software
-Practice and Experience 27:983-993, 1997), which is guaranteed to be <tt>O(N
-log N)</tt> in the worst case without incurring additional overhead in the
-average case. Most C++ library implementers already do this, and there
-is no reason not to guarantee it in the standard.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 25.3.1.1 [sort], change the complexity to "O(N log N)", and remove footnote 266:
-</p>
-
-<blockquote>
-<p>
-<i>Complexity:</i> <del>Approximately</del> <ins>O(</ins><i>N</i> log(<i>N</i>)<ins>)</ins> (where <i>N</i> == <i>last</i> - <i>first</i> )
-comparisons<del> on the average</del>.<del><sup>266)</sup></del>
-</p>
-<p>
-<del><sup>266)</sup>
-If the worst case behavior is important <tt>stable_sort()</tt> (25.3.1.2) or <tt>partial_sort()</tt>
-(25.3.1.3) should be used.</del>
-</p>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="714"></a>714. <tt>search_n</tt> complexity is too lax</h3>
-<p><b>Section:</b> 25.1.12 [alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The complexity for <tt>search_n</tt> (25.1.12 [alg.search] par 7) is specified as "At most
-(last - first ) * count applications of the corresponding predicate if
-count is positive, or 0 otherwise." This is unnecessarily pessimistic.
-Regardless of the value of count, there is no reason to examine any
-element in the range more than once.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the complexity to "At most (last - first) applications of the corresponding predicate".
-</p>
-
-<blockquote>
-<pre>template&lt;class ForwardIterator, class Size, class T&gt;
- ForwardIterator
- search_n(ForwardIterator first , ForwardIterator last , Size count ,
- const T&amp; value );
-
-template&lt;class ForwardIterator, class Size, class T,
- class BinaryPredicate&gt;
- ForwardIterator
- search_n(ForwardIterator first , ForwardIterator last , Size count ,
- const T&amp; value , BinaryPredicate pred );
-</pre>
-<blockquote>
-<p>
-<i>Complexity:</i> At most <tt>(last - first ) <del>* count</del></tt> applications of the corresponding predicate
-<del>if <tt>count</tt> is positive, or 0 otherwise</del>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="716"></a>716. Production in [re.grammar] not actually modified</h3>
-<p><b>Section:</b> 28.13 [re.grammar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-08-31</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-TR1 7.13 [tr.re.grammar]/3 and C++0x WP 28.13 [re.grammar]/3 say:
-</p>
-
-<blockquote>
-<p>
-The following productions within the ECMAScript grammar are modified as follows:
-</p>
-
-<blockquote><pre>CharacterClass ::
-[ [lookahead &#8713; {^}] ClassRanges ]
-[ ^ ClassRanges ]
-</pre></blockquote>
-
-</blockquote>
-
-<p>
-This definition for <tt>CharacterClass</tt> appears to be exactly identical to that in ECMA-262.
-</p>
-
-<p>
-Was an actual modification intended here and accidentally omitted, or was this production accidentally included?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove this mention of the CharacterClass production.
-</p>
-
-<blockquote><pre><del>CharacterClass ::
-[ [lookahead &#8713; {^}] ClassRanges ]
-[ ^ ClassRanges ]</del>
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="718"></a>718. <tt>basic_string</tt> is not a sequence</h3>
-<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Paragraph 21.3 [basic.string]/3 states:
-</p>
-
-<blockquote>
-<p>
-The class template <tt>basic_string</tt> conforms to the requirements for a
-Sequence (23.1.1) and for a Reversible Container (23.1).
-</p>
-</blockquote>
-
-<p>
-First of all, 23.1.3 [sequence.reqmts] is no longer "Sequence" but "Sequence container".
-Secondly, after the resent changes to containers (<tt>emplace</tt>, <tt>push_back</tt>,
-<tt>const_iterator</tt> parameters to <tt>insert</tt> and <tt>erase</tt>), <tt>basic_string</tt> is not
-even close to conform to the current requirements.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<ul>
-<li>emplace, for example, may not make sense for strings. Is also likely suboptimal</li>
-<li>with concepts do we need to maintain string as sequence container?</li>
-<li>One approach might be to say something like: string is a sequence except it doesn't have these functions</li>
-</ul>
-<ul>
-<li>basic_string already has push_back</li>
-<li>const_iterator parameters to insert and erase should be added to basic_string</li>
-<li>this leaves emplace to handle -- we have the following options:
-<ul>
-<li>option 1: add it to string even though it's optional</li>
-<li>option 2: make emplace optional to sequences (move from table 89 to 90)</li>
-<li>option 3: say string not sequence (the proposal),</li>
-<li>option 4: add an exception to basic string wording.</li>
-</ul>
-</li>
-</ul>
-General consensus is to suggest option 2.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove this sentence, in recognition of the fact that <tt>basic_string</tt> is
-not just a <tt>vector</tt>-light for literal types, but something quite
-different, a string abstraction in its own right.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="719"></a>719. <tt>std::is_literal</tt> type traits should be provided</h3>
-<p><b>Section:</b> 20.5 [meta] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-08-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Since the inclusion of <tt>constexpr</tt> in the standard draft N2369 we have
-a new type category "literal", which is defined in 3.9 [basic.types]/p.11:
-</p>
-
-<blockquote>
-<p>
--11- A type is a <i>literal</i> type if it is:
-</p>
-<ul>
-<li>a scalar type; or</li>
-<li><p>a class type (clause 9) with</p>
-<ul>
-<li>a trivial copy constructor,</li>
-<li>a trivial destructor,</li>
-<li>at least one constexpr constructor other than the copy constructor,</li>
-<li>no virtual base classes, and</li>
-<li>all non-static data members and base classes of literal types; or</li>
-</ul>
-</li>
-<li>an array of literal type.</li>
-</ul>
-</blockquote>
-
-<p>
-I strongly suggest that the standard provides a type traits for
-literal types in 20.5.4.3 [meta.unary.prop] for several reasons:
-</p>
-
-<ol type="a">
-<li>To keep the traits in sync with existing types.</li>
-<li>I see many reasons for programmers to use this trait in template
- code to provide optimized template definitions for these types,
- see below.</li>
-<li>A user-provided definition of this trait is practically impossible
-to write portably.</li>
-</ol>
-
-<p>
-The special problem of reason (c) is that I don't see currently a
-way to portably test the condition for literal class types:
-</p>
-
-<blockquote>
-<ul>
-<li>at least one constexpr constructor other than the copy constructor,</li>
-</ul>
-</blockquote>
-
-<p>
-Here follows a simply example to demonstrate it's usefulness:
-</p>
-
-<blockquote><pre>template &lt;typename T&gt;
-constexpr typename std::enable_if&lt;std::is_literal&lt;T&gt;::value, T&gt;::type
-abs(T x) {
- return x &lt; T() ? -x : x;
-}
-
-template &lt;typename T&gt;
-typename std::enable_if&lt;!std::is_literal&lt;T&gt;::value, T&gt;::type
-abs(const T&amp; x) {
- return x &lt; T() ? -x : x;
-}
-</pre></blockquote>
-
-<p>
-Here we have the possibility to provide a general <tt>abs</tt> function
-template that can be used in ICE's if it's argument is a literal
-type which's value is a constant expression, otherwise we
-have an optimized version for arguments which are expensive
-to copy and therefore need the usage of arguments of
-reference type (instead of <tt>const T&amp;</tt> we could decide to
-use <tt>T&amp;&amp;</tt>, but that is another issue).
-</p>
-
-<p><i>[
-Alisdair is considering preparing a paper listing a number of missing
-type traits, and feels that it might be useful to handle them all
-together rather than piecemeal. This would affect issue 719 and 750.
-These two issues should move to OPEN pending AM paper on type traits.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.5.2 [meta.type.synop] in the group "type properties",
-just below the line
-</p>
-
-<blockquote><pre>template &lt;class T&gt; struct is_pod;
-</pre></blockquote>
-
-<p>
-add a new one:
-</p>
-
-<blockquote><pre>template &lt;class T&gt; struct is_literal;
-</pre></blockquote>
-
-<p>
-In 20.5.4.3 [meta.unary.prop], table Type Property Predicates, just
-below the line for the <tt>is_pod</tt> property add a new line:
-</p>
-
-<table border="1">
-<tbody><tr>
-<th>Template</th><th>Condition</th><th>Preconditions</th>
-</tr>
-<tr>
-<td><tt>template &lt;class T&gt; struct is_literal;</tt></td>
-<td><tt>T</tt> is a literal type (3.9)</td>
-<td><tt>T</tt> shall be a complete type, an
-array of unknown bound, or
-(possibly cv-qualified) <tt>void</tt>.</td>
-</tr>
-</tbody></table>
-
-
-
-
-
-
-<hr>
-<h3><a name="720"></a>720. Omissions in constexpr usages</h3>
-<p><b>Section:</b> 23.2.1 [array], 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-08-25</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<ol>
-<li>
-The member function <tt>bool array&lt;T,N&gt;::empty() const</tt> should be a
-<tt>constexpr</tt> because this is easily to proof and to implement following it's operational
-semantics defined by Table 87 (Container requirements) which says: <tt>a.size() == 0</tt>.
-</li>
-<li>
-The member function <tt>bool bitset&lt;N&gt;::test() const</tt> must be a
-<tt>constexpr</tt> (otherwise it would violate the specification of <tt>constexpr
-bitset&lt;N&gt;::operator[](size_t) const</tt>, because it's return clause delegates to <tt>test()</tt>).
-</li>
-<li>
-I wonder how the constructor <tt>bitset&lt;N&gt;::bitset(unsigned long)</tt> can
-be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
-c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
-non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
-initialisation. What have I overlooked here?
-</li>
-</ol>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-We handle this as two parts
-</p>
-<ol>
-<li>
-The proposed resolution is correct; move to ready.
-</li>
-<li>
-The issue points out a real problem, but the issue is larger than just
-this solution. We believe a paper is needed, applying the full new
-features of C++ (including extensible literals) to update <tt>std::bitset</tt>.
-We note that we do not consider this new work, and that is should be
-handled by the Library Working Group.
-</li>
-</ol>
-<p>
-In order to have a consistent working paper, Alisdair and Daniel produced a new wording for the resolution.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>In the class template definition of 23.2.1 [array]/p. 3 change</p>
-<blockquote><pre><ins>constexpr</ins> bool empty() const;
-</pre></blockquote>
-</li>
-
-<li>
-<p>In the class template definition of 23.3.5 [template.bitset]/p. 1 change</p>
-<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
-</pre></blockquote>
-
-<p>
-and in 23.3.5.2 [bitset.members] change
-</p>
-
-<blockquote><pre><ins>constexpr</ins> bool test(size_t pos ) const;
-</pre></blockquote>
-
-</li>
-</ol>
-
-
-
-
-
-<hr>
-<h3><a name="721"></a>721. <tt>wstring_convert</tt> inconsistensies</h3>
-<p><b>Section:</b> 22.1.3.2.2 [conversions.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-08-27</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Paragraph 3 says that the <tt>Codecvt</tt> template parameter shall meet the
-requirements of <tt>std::codecvt</tt>, even though <tt>std::codecvt</tt> itself cannot
-be used (because of a protected destructor).
-</p>
-
-<p>
-How are we going to explain this code to beginning programmers?
-</p>
-
-<blockquote><pre>template&lt;class I, class E, class S&gt;
-struct codecvt : std::codecvt&lt;I, E, S&gt;
-{
- ~codecvt()
- { }
-};
-
-void main()
-{
- std::wstring_convert&lt;codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt; compiles_ok;
-
- std::wstring_convert&lt;std::codecvt&lt;wchar_t, char, std::mbstate_t&gt; &gt; not_ok;
-}
-</pre></blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="723"></a>723. <tt>basic_regex</tt> should be moveable</h3>
-<p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-08-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-According to the current state of the standard draft, the class
-template <tt>basic_regex</tt>, as described in 28.8 [re.regex]/3, is
-neither <tt>MoveConstructible</tt> nor <tt>MoveAssignable</tt>.
-IMO it should be, because typical regex state machines tend
-to have a rather large data quantum and I have seen several
-use cases, where a factory function returns regex values,
-which would take advantage of moveabilities.
-</p>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-Needs wording for the semantics, the idea is agreed upon.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<ol type="a">
-<li>
-<p>
-In the header <tt>&lt;regex&gt;</tt> synopsis 28.4 [re.syn], just below the function
-template <tt>swap</tt> add two further overloads:
-</p>
-<blockquote><pre>template &lt;class charT, class traits&gt;
- void swap(basic_regex&lt;charT, traits&gt;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
-<ins>template &lt;class charT, class traits&gt;
- void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
-template &lt;class charT, class traits&gt;
- void swap(basic_regex&lt;charT, traits&gt;&amp; e1, basic_regex&lt;charT, traits&gt;&amp;&amp; e2);</ins>
-</pre></blockquote>
-<p>
-In the class definition of <tt>basic_regex</tt>, just below 28.8 [re.regex]/3,
-perform the following changes:
-</p>
-</li>
-
-<li>
-<p>Just after the copy c'tor:</p>
-<blockquote><pre>basic_regex(basic_regex&amp;&amp;);
-</pre></blockquote>
-</li>
-
-<li>
-<p>Just after the copy-assignment op.:</p>
-<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
-</pre></blockquote>
-</li>
-
-<li>
-<p>Just after the first <tt>assign</tt> overload insert:</p>
-<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
-</pre></blockquote>
-</li>
-
-<li>
-<p>Change the current <tt>swap</tt> function to read:</p>
-<blockquote><pre>void swap(basic_regex&amp;&amp;);
-</pre></blockquote>
-</li>
-
-<li>
-<p>In 28.8.2 [re.regex.construct], just below the copy c'tor add a
-corresponding member definition of:</p>
-<blockquote><pre>basic_regex(basic_regex&amp;&amp;);
-</pre></blockquote>
-</li>
-
-<li>
-<p>Also in 28.8.2 [re.regex.construct], just below the copy assignment
-c'tor add a corresponding member definition of:</p>
-<blockquote><pre>basic_regex&amp; operator=(basic_regex&amp;&amp;);
-</pre></blockquote>
-</li>
-
-<li>
-<p>In 28.8.3 [re.regex.assign], just below the first <tt>assign</tt> overload add
-a corresponding member definition of:</p>
-<blockquote><pre>basic_regex&amp; assign(basic_regex&amp;&amp; that);
-</pre></blockquote>
-</li>
-
-<li>
-<p>In 28.8.6 [re.regex.swap], change the signature of <tt>swap</tt> to
-say:</p>
-<blockquote><pre>void swap(basic_regex&amp;&amp; e);
-</pre></blockquote>
-</li>
-
-<li>
-<p>In 28.8.7.1 [re.regex.nmswap], just below the single binary <tt>swap</tt>
-function, add the two missing overloads:</p>
-<blockquote><pre>template &lt;class charT, class traits&gt;
- void swap(basic_regex&lt;charT, traits&gt;&amp;&amp; e1, basic_regex&lt;charT, traits&gt;&amp; e2);
-template &lt;class charT, class traits&gt;
- void swap(basic_regex&lt;charT, traits&gt;&amp; e1, basic_regex&lt;charT, traits&gt;&amp;&amp; e2);
-</pre></blockquote>
-</li>
-</ol>
-
-<p>
-Of course there would be need of corresponding proper standardese
-to describe these additions.
-</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="724"></a>724. <tt>DefaultConstructible</tt> is not defined</h3>
-<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2007-09-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The <tt>DefaultConstructible</tt> requirement is referenced in
-several places in the August 2007 working draft
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf">N2369</a>,
-but is not defined anywhere.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Walking into the default/value-initialization mess...
-</p>
-<p>
-Why two lines? Because we need both expressions to be valid.
-</p>
-<p>
-AJM not sure what the phrase "default constructed" means. This is
-unfortunate, as the phrase is already used 24 times in the library!
-</p>
-<p>
-Example: const int would not accept first line, but will accept the second.
-</p>
-<p>
-This is an issue that must be solved by concepts, but we might need to solve it independantly first.
-</p>
-<p>
-It seems that the requirements are the syntax in the proposed first
-column is valid, but not clear what semantics we need.
-</p>
-<p>
-A table where there is no post-condition seems odd, but appears to sum up our position best.
-</p>
-<p>
-At a minimum an object is declared and is destuctible.
-</p>
-<p>
-Move to open, as no-one happy to produce wording on the fly.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In section 20.1.1 [utility.arg.requirements], before table 33, add the
-following table:
-</p>
-
-<p style="text-align: center;" align="center">Table 33: <tt>DefaultConstructible</tt> requirements</p>
-
-<div align="center">
-
-<table style="border-collapse: collapse;" border="0" cellpadding="0" cellspacing="0">
- <tbody><tr>
- <td style="border-style: solid none double solid; border-color: navy -moz-use-text-color navy navy; border-width: 1pt medium 1.5pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
- <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">expression</p>
- </td>
- <td style="border-style: solid solid double none; border-color: navy navy navy -moz-use-text-color; border-width: 1pt 1pt 1.5pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
- <p style="margin: 0in 0in 0.0001pt; text-align: center;" align="center">post-condition</p>
- </td>
- </tr>
- <tr>
- <td style="border-style: none none solid solid; border-color: -moz-use-text-color -moz-use-text-color navy navy; border-width: medium medium 1pt 1pt; padding: 0in 5.4pt; width: 85.5pt;" valign="top" width="114">
- <p style="margin: 0in 0in 0.0001pt;"><tt>T
- t;</tt><br>
- <tt>T()</tt></p>
- </td>
- <td style="border-style: none solid solid none; border-color: -moz-use-text-color navy navy -moz-use-text-color; border-width: medium 1pt 1pt medium; padding: 0in 5.4pt; width: 243pt;" valign="top" width="324">
- <p style="margin: 0in 0in 0.0001pt;"><tt>T</tt>
- is <i>default constructed.</i></p>
- </td>
- </tr>
-</tbody></table>
-
-</div>
-
-
-
-
-
-
-<hr>
-<h3><a name="726"></a>726. Missing <tt>regex_replace()</tt> overloads</h3>
-<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Two overloads of <tt>regex_replace()</tt> are currently provided:
-</p>
-
-<blockquote><pre>template &lt;class OutputIterator, class BidirectionalIterator,
- class traits, class charT&gt;
- OutputIterator
- regex_replace(OutputIterator out,
- BidirectionalIterator first, BidirectionalIterator last,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const basic_string&lt;charT&gt;&amp; fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-
-template &lt;class traits, class charT&gt;
- basic_string&lt;charT&gt;
- regex_replace(const basic_string&lt;charT&gt;&amp; s,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const basic_string&lt;charT&gt;&amp; fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-</pre></blockquote>
-
-<ol>
-<li>Overloads taking <tt>const charT *</tt> are provided for <tt>regex_match()</tt> and
-<tt>regex_search()</tt>, but not <tt>regex_replace()</tt>. This is inconsistent.</li>
-<li>
-<p>The absence of <tt>const charT *</tt> overloads prevents ordinary-looking code from compiling, such as:</p>
-
-<blockquote><pre>const string s("kitten");
-const regex r("en");
-cout &lt;&lt; regex_replace(s, r, "y") &lt;&lt; endl;
-</pre></blockquote>
-
-<p>
-The compiler error message will be something like "could not deduce
-template argument for 'const std::basic_string&lt;_Elem&gt; &amp;' from 'const
-char[1]'".
-</p>
-
-<p>
-Users expect that anything taking a <tt>basic_string&lt;charT&gt;</tt> can also take a
-<tt>const charT *</tt>. In their own code, when they write a function taking
-<tt>std::string</tt> (or <tt>std::wstring</tt>), they can pass a <tt>const char *</tt> (or <tt>const
-wchar_t *</tt>), thanks to <tt>basic_string</tt>'s implicit constructor. Because the
-regex algorithms are templated on <tt>charT</tt>, they can't rely on
-<tt>basic_string</tt>'s implicit constructor (as the compiler error message
-indicates, template argument deduction fails first).
-</p>
-
-<p>
-If a user figures out what the compiler error message means, workarounds
-are available - but they are all verbose. Explicit template arguments
-could be given to <tt>regex_replace()</tt>, allowing <tt>basic_string</tt>'s implicit
-constructor to be invoked - but <tt>charT</tt> is the last template argument, not
-the first, so this would be extremely verbose. Therefore, constructing
-a <tt>basic_string</tt> from each C string is the simplest workaround.
-</p>
-</li>
-
-<li>
-There is an efficiency consideration: constructing <tt>basic_string</tt>s can
-impose performance costs that could be avoided by a library
-implementation taking C strings and dealing with them directly.
-(Currently, for replacement sources, C strings can be converted into
-iterator pairs at the cost of verbosity, but for format strings, there
-is no way to avoid constructing a <tt>basic_string</tt>.)
-</li>
-</ol>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-We note that Boost already has these overloads. However, the proposed
-wording is provided only for 28.11.4 [re.alg.replace]; wording is needed for the synopsis
-as well. We also note that this has impact on <tt>match_results::format</tt>,
-which may require further overloads.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Provide additional overloads for <tt>regex_replace()</tt>: one additional
-overload of the iterator-based form (taking <tt>const charT* fmt</tt>), and three
-additional overloads of the convenience form (one taking <tt>const charT*
-str</tt>, another taking <tt>const charT* fmt</tt>, and the third taking both <tt>const
-charT* str</tt> and <tt>const charT* fmt</tt>). 28.11.4 [re.alg.replace]:
-</p>
-
-<blockquote>
-<pre>template &lt;class OutputIterator, class BidirectionalIterator,
- class traits, class charT&gt;
- OutputIterator
- regex_replace(OutputIterator out,
- BidirectionalIterator first, BidirectionalIterator last,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const basic_string&lt;charT&gt;&amp; fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-
-<ins>template &lt;class OutputIterator, class BidirectionalIterator,
- class traits, class charT&gt;
- OutputIterator
- regex_replace(OutputIterator out,
- BidirectionalIterator first, BidirectionalIterator last,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const charT* fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);</ins>
-</pre>
-<p>...</p>
-<pre>template &lt;class traits, class charT&gt;
- basic_string&lt;charT&gt;
- regex_replace(const basic_string&lt;charT&gt;&amp; s,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const basic_string&lt;charT&gt;&amp; fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-
-<ins>template &lt;class traits, class charT&gt;
- basic_string&lt;charT&gt;
- regex_replace(const basic_string&lt;charT&gt;&amp; s,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const charT* fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);</ins>
-
-<ins>template &lt;class traits, class charT&gt;
- basic_string&lt;charT&gt;
- regex_replace(const charT* s,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const basic_string&lt;charT&gt;&amp; fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);</ins>
-
-<ins>template &lt;class traits, class charT&gt;
- basic_string&lt;charT&gt;
- regex_replace(const charT* s,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- const charT* fmt,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);</ins>
-</pre>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="727"></a>727. <tt>regex_replace()</tt> doesn't accept <tt>basic_string</tt>s with custom traits and allocators</h3>
-<p><b>Section:</b> 28.11.4 [re.alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2007-09-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#re.alg.replace">active issues</a> in [re.alg.replace].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.alg.replace">issues</a> in [re.alg.replace].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>regex_match()</tt> and <tt>regex_search()</tt> take <tt>const basic_string&lt;charT, ST,
-SA&gt;&amp;</tt>. <tt>regex_replace()</tt> takes <tt>const basic_string&lt;charT&gt;&amp;</tt>. This prevents
-<tt>regex_replace()</tt> from accepting <tt>basic_string</tt>s with custom traits and
-allocators.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Overloads of <tt>regex_replace()</tt> taking <tt>basic_string</tt> should be additionally
-templated on <tt>class ST, class SA</tt> and take <tt>const basic_string&lt;charT, ST,
-SA&gt;&amp;</tt>. Consistency with <tt>regex_match()</tt> and <tt>regex_search()</tt> would place
-<tt>class ST, class SA</tt> as the first template arguments; compatibility with
-existing code using TR1 and giving explicit template arguments to
-<tt>regex_replace()</tt> would place <tt>class ST, class SA</tt> as the last template
-arguments.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="728"></a>728. Problem in [rand.eng.mers]/6</h3>
-<p><b>Section:</b> 26.4.3.2 [rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given
-as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization
-of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate
-for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in
-which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M.
-Matsumoto have chosen a dif ferent multiplier for their 64 bit Mersenne Twister
-[<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-64.c">reference</a>].
-</p>
-
-<p>
-I see two possible resolutions:
-</p>
-
-<ol type="a">
-<li>Restrict the parameter <tt>W</tt> of the <tt>mersenne_twister_template</tt> to values of 32 or 64 and use the
-multiplier from [the above reference] for the 64-bit case (my preference)</li>
-<li>Interpret the state array for any <tt>W</tt> as a 32-bit array of appropriate length (and a specified byte
-order) and always employ the 32-bit algorithm for seeding
-</li>
-</ol>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for further discussion.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Stephan Tolksdorf has additional comments on N2424. He comments: "there
-is a typo in the required behaviour for mt19937_64: It should be the
-10000th (not 100000th) invocation whose value is given, and the value
-should be 9981545732273789042 (not 14002232017267485025)." These values
-need checking.
-</p>
-<p>
-Take the proposed recommendation in N2424 and move to REVIEW.
-</p>
-</blockquote>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for the proposed resolution.
-</p>
-
-<p><i>[
-Stephan Tolksdorf adds pre-Bellevue:
-]</i></p>
-
-
-<blockquote>
-I support the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>,
-but there is a typo in the
-required behaviour for <tt>mt19937_64</tt>: It should be the 10000<sup>th</sup> (not
-100000<sup>th</sup>) invocation whose value is given, and the value should be
-9981545732273789042 (not 14002232017267485025). The change to para. 8
-proposed by Charles Karney should also be included in the proposed
-wording.
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-Note the main part of the issue is resolved by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>.
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="732"></a>732. Defect in [rand.dist.samp.genpdf]</h3>
-<p><b>Section:</b> 26.4.8.5.3 [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a></p>
-<p><b>Discussion:</b></p>
-<p>
-26.4.8.5.3 [rand.dist.samp.genpdf] describes the interface for a distribution template that is
-meant to simulate random numbers from any general distribution given only the density and the
-support of the distribution. I'm not aware of any general purpose algorithm that would be capable
-of correctly and efficiently implementing the described functionality. From what I know, this is
-essentially an unsolved research problem. Existing algorithms either require more knowledge
-about the distribution and the problem domain or work only under very limited circumstances.
-Even the state of the art special purpose library UNU.RAN does not solve the problem in full
-generality, and in any case, testing and customer support for such a library feature would be a
-nightmare.
-</p>
-
-<p>
-<b>Possible resolution:</b> For these reasons, I propose to delete section 26.4.8.5.3 [rand.dist.samp.genpdf].
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Disagreement persists.
-</p>
-<p>
-Objection to this issue is that this function takes a general functor.
-The general approach would be to normalize this function, integrate it,
-and take the inverse of the integral, which is not possible in general.
-An example function is sin(1+n*x) -- for any spatial frequency that the
-implementor chooses, there is a value of n that renders that choice
-arbitrarily erroneous.
-</p>
-<p>
-Correction: The formula above should instead read 1+sin(n*x).
-</p>
-<p>
-Objector proposes the following possible compromise positions:
-</p>
-<ul>
-<li>
-rand.dist.samp.genpdf takes an number of points so that implementor need not guess.
-</li>
-<li>replace rand.disk.samp.genpdf with an extension to either or both
-of the discrete functions to take arguments that take a functor and
-number of points in place of the list of probabilities. Reference
-issues 793 and 794.
-</li>
-</ul>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for the proposed resolution.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="734"></a>734. Unnecessary restriction in [rand.dist.norm.chisq]</h3>
-<p><b>Section:</b> 26.4.8.4.3 [rand.dist.norm.chisq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>chi_squared_distribution</tt>, <tt>fisher_f_distribution</tt> and <tt>student_t_distribution</tt>
-have parameters for the "degrees of freedom" <tt>n</tt> and <tt>m</tt> that are specified as integers. For the
-following two reasons this is an unnecessary restriction: First, in many applications such as
-Bayesian inference or Monte Carlo simulations it is more convenient to treat the respective param-
-eters as continuous variables. Second, the standard non-naive algorithms (i.e.
-O(1) algorithms)
-for simulating from these distributions work with floating-point parameters anyway (all three
-distributions could be easily implemented using the Gamma distribution, for instance).
-</p>
-
-<p>
-Similar arguments could in principle be made for the parameters <tt>t</tt> and <tt>k</tt> of the discrete
-<tt>binomial_distribution</tt> and <tt>negative_binomial_distribution</tt>, though in both cases continuous
-parameters are less frequently used in practice and in case of the <tt>binomial_distribution</tt>
-the implementation would be significantly complicated by a non-discrete parameter (in most
-implementations one would need an approximation of the log-gamma function instead of just the
-log-factorial function).
-</p>
-
-<p>
-<b>Possible resolution:</b> For these reasons, I propose to change the type of the respective parameters
-to double.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-In N2424. Not wildly enthusiastic, not really felt necessary. Less
-frequently used in practice. Not terribly bad either. Move to OPEN.
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-Marc Paterno: The generalizations were explicitly left out when designing the facility. It's harder to test.
-</p>
-<p>
-Marc Paterno: Ask implementers whether floating-point is a significant burden.
-</p>
-<p>
-Alisdair: It's neater to do it now, do ask Bill Plauger.
-</p>
-<p>
-Disposition: move to review with the option for "NAD" if it's not straightforward to implement; unanimous consent.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for the proposed resolution.
-</p>
-
-<p><i>[
-Stephan Tolksdorf adds pre-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-In 26.4.8.4.3 [rand.dist.norm.chisq]:
-</p>
-
-<blockquote>
-<p>
-Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
-</p>
-
-<p>
-Replace both occurrences of "<tt>explicit chi_squared_distribution(int n = 1);</tt>"
-with "<tt>explicit chi_squared_distribution(RealType n = 1);</tt>".
-</p>
-
-<p>
-Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
-</p>
-
-</blockquote>
-
-<p>
-In 26.4.8.4.5 [rand.dist.norm.f]:
-</p>
-<blockquote>
-<p>
-Delete ", where <tt>m</tt> and <tt>n</tt> are positive integers" in the first paragraph.
-</p>
-
-<p>
-Replace both occurrences of
-</p>
-<blockquote><pre>explicit fisher_f_distribution(int m = 1, int n = 1);
-</pre></blockquote>
-<p>
-with
-</p>
-<blockquote><pre>explicit fisher_f_distribution(RealType m = 1, RealType n = 1);
-</pre></blockquote>
-
-<p>
-Replace both occurrences of "<tt>int m() const;" with "RealType m() const;</tt>".
-</p>
-
-<p>
-Replace both occurrences of "<tt>int n() const;" with "RealType n() const;</tt>".
-</p>
-</blockquote>
-
-<p>
-In 26.4.8.4.6 [rand.dist.norm.t]:
-</p>
-
-<blockquote>
-<p>
-Delete ", where <tt>n</tt> is a positive integer" in the first paragraph.
-</p>
-
-<p>
-Replace both occurrences of "<tt>explicit student_t_distribution(int n = 1);</tt>"
-with "<tt>explicit student_t_distribution(RealType n = 1);</tt>".
-</p>
-
-<p>
-Replace both occurrences of "<tt>int n() const;</tt>" with "<tt>RealType n() const;</tt>".
-</p>
-</blockquote>
-
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="742"></a>742. Enabling <tt>swap</tt> for proxy iterators</h3>
-<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-This issue was split from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>. <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a> now just
-deals with changing the requirements of <tt>T</tt> in the <tt>Swappable</tt>
-requirement from <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> to
-<tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>.
-</p>
-
-<p>
-This issue seeks to widen the <tt>Swappable</tt> requirement to support proxy iterators. Here
-is example code:
-</p>
-
-<blockquote><pre>namespace Mine {
-
-template &lt;class T&gt;
-struct proxy {...};
-
-template &lt;class T&gt;
-struct proxied_iterator
-{
- typedef T value_type;
- typedef proxy&lt;T&gt; reference;
- reference operator*() const;
- ...
-};
-
-struct A
-{
- // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
- void swap(A&amp;);
- ...
-};
-
-void swap(A&amp;, A&amp;);
-void swap(proxy&lt;A&gt;, A&amp;);
-void swap(A&amp;, proxy&lt;A&gt;);
-void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
-
-} // Mine
-
-...
-
-Mine::proxied_iterator&lt;Mine::A&gt; i(...)
-Mine::A a;
-<b>swap(*i1, a);</b>
-</pre></blockquote>
-
-<p>
-The key point to note in the above code is that in the call to <tt>swap</tt>, <tt>*i1</tt>
-and <tt>a</tt> are different types (currently types can only be <tt>Swappable</tt> with the
-same type). A secondary point is that to support proxies, one must be able to pass rvalues
-to <tt>swap</tt>. But note that I am not stating that the general purpose <tt>std::swap</tt>
-should accept rvalues! Only that overloaded <tt>swap</tt>s, as in the example above, be allowed
-to take rvalues.
-</p>
-
-<p>
-That is, no standard library code needs to change. We simply need to have a more flexible
-definition of <tt>Swappable</tt>.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-While we believe Concepts work will define a swappable concept, we
-should still resolve this issue if possible to give guidance to the
-Concepts work.
-</p>
-<p>
-Would an ambiguous swap function in two namespaces found by ADL break
-this wording? Suggest that the phrase "valid expression" means such a
-pair of types would still not be swappable.
-</p>
-<p>
-Motivation is proxy-iterators, but facility is considerably more
-general. Are we happy going so far?
-</p>
-<p>
-We think this wording is probably correct and probably an improvement on
-what's there in the WP. On the other hand, what's already there in the
-WP is awfully complicated. Why do we need the two bullet points? They're
-too implementation-centric. They don't add anything to the semantics of
-what swap() means, which is there in the post-condition. What's wrong
-with saying that types are swappable if you can call swap() and it
-satisfies the semantics of swapping?
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.1.1 [utility.arg.requirements]:
-</p>
-
-<blockquote>
-
-<p>
--1- The template definitions in the C++ Standard Library refer to various
-named requirements whose details are set out in tables 31-38. In these
-tables, <tt>T</tt> <ins>and <tt>V</tt> are</ins> <del>is a</del> type<ins>s</ins> to be supplied by a C++ program
-instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
-values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
-lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
-<tt>const</tt>) <tt>T</tt>; <del>and</del> <tt>rv</tt> is a non-<tt>const</tt>
-rvalue of type <tt>T</tt><ins>; <tt>w</tt> is a value of type <tt>T</tt>; and <tt>v</tt> is a value of type <tt>V</tt></ins>.
-</p>
-
-<table border="1">
-<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
-<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
-<tr><td><tt>swap(<del>s</del><ins>w</ins>,<del>t</del><ins>v</ins>)</tt></td><td><tt>void</tt></td>
-<td><del><tt>t</tt></del><ins><tt>w</tt></ins> has the value originally
-held by <del><tt>u</tt></del><ins><tt>v</tt></ins>, and
-<del><tt>u</tt></del><ins><tt>v</tt></ins> has the value originally held
-by <del><tt>t</tt></del><ins><tt>w</tt></ins></td></tr>
-<tr><td colspan="3">
-<p>
-The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
-</p>
-<ul>
-<li>
-<tt>T</tt> is <tt>Swappable</tt> if <ins><tt>T</tt> and <tt>V</tt> are
-the same type and </ins> <tt>T</tt> satisfies the
-<del><tt>CopyConstructible</tt></del>
-<ins><tt>MoveConstructible</tt></ins> requirements (Table <del>34</del>
-<ins>33</ins>) and the <del><tt>CopyAssignable</tt></del>
-<ins><tt>MoveAssignable</tt></ins> requirements (Table <del>36</del>
-<ins>35</ins>);
-</li>
-<li>
-<tt>T</tt> is <tt>Swappable</tt> <ins>with <tt>V</tt></ins> if a namespace scope function named
-<tt>swap</tt> exists in the same namespace as the definition of
-<tt>T</tt> <ins>or <tt>V</tt></ins>, such that the expression
-<tt>swap(<del>t</del><ins>w</ins>,<del>u</del> <ins>v</ins>)</tt> is valid and has the
-semantics described in this table.
-</li>
-</ul>
-</td></tr>
-</tbody></table>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="747"></a>747. We have 3 separate type traits to identify classes supporting no-throw operations</h3>
-<p><b>Section:</b> 20.5.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-We have 3 separate type traits to identify classes supporting no-throw
-operations, which are very useful when trying to provide exception safety
-guarantees. However, I'm not entirely clear on what the current wording
-requires of a conforming implementation. To quote from
-<tt>has_nothrow_default_constructor</tt>:
-</p>
-<blockquote><p>
-or <tt>T</tt> is a class type with a default constructor that is known not to throw
-any exceptions
-</p></blockquote>
-<p>
-What level of magic do we expect to deduce if this is known?
-</p>
-<p>
-E.g.
-</p>
-
-<blockquote><pre>struct test{
- int x;
- test() : x() {}
-};
-</pre></blockquote>
-<p>
-Should I expect a conforming compiler to
- <tt>assert( has_nothrow_constructor&lt;test&gt;::value )</tt>
-</p>
-<p>
-Is this a QoI issue?
-</p>
-<p>
-Should I expect to 'know' only if-and-only-if there is an inline definition
-available?
-</p>
-<p>
-Should I never expect that to be true, and insist that the user supplies an
-empty throw spec if they want to assert the no-throw guarantee?
-</p>
-<p>
-It would be helpful to maybe have a footnote explaining what is required,
-but right now I don't know what to suggest putting in the footnote.
-</p>
-<p>
-(agreement since is that trivial ops and explicit no-throws are required.
-Open if QoI should be allowed to detect further)
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-This looks like a QoI issue.
-In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI.
-Move to OPEN. Need to talk to Core about this.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="750"></a>750. The current definition for <tt>is_convertible</tt> requires that the type be
-implicitly convertible, so explicit constructors are ignored.</h3>
-<p><b>Section:</b> 20.5.5 [meta.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-With the pending arrival of explicit conversion functions though, I'm
-wondering if we want an additional trait, <tt>is_explictly_convertible</tt>?
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Alisdair is considering preparing a paper listing a number of missing
-type traits, and feels that it might be useful to handle them all
-together rather than piecemeal. This would affect issue 719 and 750.
-These two issues should move to OPEN pending AM paper on type traits.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="751"></a>751. change pass-by-reference members of <tt>vector&lt;bool&gt;</tt> to pass-by-value?</h3>
-<p><b>Section:</b> 23.2.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-A number of vector&lt;bool&gt; members take const bool&amp; as arguments.
-Is there any chance we could change them to pass-by-value or would I
-be wasting everyone's time if wrote up an issue?
-</p>
-
-<p><i>[
-post Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-As we understand it, the original requester (Martin Sebor) would like
-for implementations to be permitted to pass-by-value. Alisdair suggests
-that if this is to be resolved, it should be resolved more generally,
-e.g. in other containers as well.
-</p>
-<p>
-We note that this would break ABI. However, we also suspect that this
-might be covered under the "as-if" rule in section 1.9.
-</p>
-<p>
-Many in the group feel that for vector&lt;bool&gt;, this is a "don't care",
-and that at this point in the process it's not worth the bandwidth.
-</p>
-<p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a> -- which was in ready status pre-Bellevue and is
-now in the working paper -- is related to this, though not a duplicate.
-</p>
-<p>
-Moving to Open with a task for Alisdair to craft a informative note to
-be put whereever appropriate in the WP. This note would clarify places
-where pass-by-const-ref can be transformed to pass-by-value under the
-as-if rule.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="752"></a>752. Allocator complexity requirement</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Hans Boehm <b>Date:</b> 2007-10-11</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Did LWG recently discuss 20.1.2 [allocator.requirements]-2, which states that "All the operations
-on the allocators are expected to be amortized constant time."?
-</p>
-<p>
-As I think I pointed out earlier, this is currently fiction for
-<tt>allocate()</tt> if it has to obtain memory from the OS, and it's unclear to
-me how to interpret this for <tt>construct()</tt> and <tt>destroy()</tt> if they deal with
-large objects. Would it be controversial to officially let these take
-time linear in the size of the object, as they already do in real life?
-</p>
-<p>
-<tt>Allocate()</tt> more blatantly takes time proportional to the size of the
-object if you mix in GC. But it's not really a new problem, and I think
-we'd be confusing things by leaving the bogus requirements there. The
-current requirement on <tt>allocate()</tt> is generally not important anyway,
-since it takes O(size) to construct objects in the resulting space.
-There are real performance issues here, but they're all concerned with
-the constants, not the asymptotic complexity.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.1.2 [allocator.requirements]/2:
-</p>
-
-<blockquote>
-<p>
--2- Table 39 describes the requirements on types manipulated through
-allocators. <del>All the operations on the allocators are expected to be
-amortized constant time.</del> Table 40 describes the
-requirements on allocator types.
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="753"></a>753. Move constructor in draft</h3>
-<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Yechezkel Mett <b>Date:</b> 2007-10-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The draft standard n2369 uses the term <i>move constructor</i> in a few
-places, but doesn't seem to define it.
-</p>
-
-<p>
-<tt>MoveConstructible</tt> requirements are defined in Table 33 in 20.1.1 [utility.arg.requirements] as
-follows:
-</p>
-
-<blockquote>
-<table border="1">
-<caption><tt>MoveConstructible</tt> requirements</caption>
-<tbody><tr>
-<th>expression</th> <th>post-condition</th>
-</tr>
-<tr>
-<td><tt>T t = rv</tt></td> <td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
-</tr>
-<tr>
-<td colspan="2">[<i>Note:</i> There is no requirement on the value of <tt>rv</tt> after the
-construction. <i>-- end note</i>]</td>
-</tr>
-</tbody></table>
-</blockquote>
-
-<p>
-(where <tt>rv</tt> is a non-const rvalue of type <tt>T</tt>).
-</p>
-
-<p>
-So I assume the move constructor is the constructor that would be used
-in filling the above requirement.
-</p>
-
-<p>
-For <tt>vector::reserve</tt>, <tt>vector::resize</tt> and the <tt>vector</tt> modifiers given in
-23.2.6.4 [vector.modifiers] we have
-</p>
-
-<blockquote>
-<i>Requires:</i> If <tt>value_type</tt> has a move constructor, that constructor shall
-not throw any exceptions.
-</blockquote>
-
-<p>
-Firstly "If <tt>value_type</tt> has a move constructor" is superfluous; every
-type which can be put into a <tt>vector</tt> has a move constructor (a copy
-constructor is also a move constructor). Secondly it means that for
-any <tt>value_type</tt> which has a throwing copy constructor and no other move
-constructor these functions cannot be used -- which I think will come
-as a shock to people who have been using such types in <tt>vector</tt> until
-now!
-</p>
-
-<p>
-I can see two ways to correct this. The simpler, which is presumably
-what was intended, is to say "If <tt>value_type</tt> has a move constructor and
-no copy constructor, the move constructor shall not throw any
-exceptions" or "If <tt>value_type</tt> has a move constructor which changes the
-value of its parameter,".
-</p>
-
-<p>
-The other alternative is add to <tt>MoveConstructible</tt> the requirement that
-the expression does not throw. This would mean that not every type
-that satisfies the <tt>CopyConstructible</tt> requirements also satisfies the
-<tt>MoveConstructible</tt> requirements. It would mean changing requirements in
-various places in the draft to allow either <tt>MoveConstructible</tt> or
-<tt>CopyConstructible</tt>, but I think the result would be clearer and
-possibly more concise too.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add new defintions to 17.1 [definitions]:
-</p>
-
-<blockquote>
-<p>
-<b>move constructor</b>
-</p>
-<p>
-a constructor which accepts only rvalue arguments of that type, and modifies the rvalue as a
-side effect during the construction.
-</p>
-<p>
-<b>move assignment operator</b>
-</p>
-<p>
-an assignment operator which accepts only rvalue arguments of that type, and modifies the rvalue as a
-side effect during the assignment.
-</p>
-<p>
-<b>move assignment</b>
-</p>
-<p>
-use of the move assignment operator.
-</p>
-</blockquote>
-
-<p><i>[
-Howard adds post-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Unfortunately I believe the wording recommended by the LWG in Bellevue is incorrect. <tt>reserve</tt> et. al. will use a move constructor
-if one is available, else it will use a copy constructor. A type may have both. If the move constructor is
-used, it must not throw. If the copy constructor is used, it can throw. The sentence in the proposed wording
-is correct without the recommended insertion. The Bellevue LWG recommended moving this issue to Ready. I am
-unfortunately pulling it back to Open. But I'm drafting wording to atone for this egregious action. :-)
-</p>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="758"></a>758. <tt>shared_ptr</tt> and <tt>nullptr</tt></h3>
-<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-10-31</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Consider the following program:
-</p>
-
-<blockquote><pre>int main() {
- shared_ptr&lt;int&gt; p(nullptr);
- return 0;
-}
-</pre></blockquote>
-
-<p>
-This program will fail to compile because <tt>shared_ptr</tt> uses the following
-template constructor to construct itself from pointers:
-</p>
-
-<blockquote><pre>template &lt;class Y&gt; shared_ptr(Y *);
-</pre></blockquote>
-
-<p>
-According
-to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">N2431</a>,
-the conversion from <tt>nullptr_t</tt> to <tt>Y *</tt> is not
-deducible, so the above constructor will not be found. There are similar problems with the
-constructors that take a pointer and a <tt>deleter</tt> or a
-pointer, a <tt>deleter</tt> and an allocator, as well as the
-corresponding forms of <tt>reset()</tt>. Note that <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a>
-will solve this problem for constructing from just <tt>nullptr</tt>, but not for constructors that use
-<tt>deleters</tt> or allocators or for <tt>reset()</tt>.
-</p>
-
-<p>
-In the case of the functions that take deleters, there is the additional
-question of what argument should be passed to the deleter when it is
-eventually called. There are two reasonable possibilities: <tt>nullptr</tt> or
-<tt>static_cast&lt;T *&gt;(0)</tt>, where <tt>T</tt> is the template argument of the
-<tt>shared_ptr</tt>. It is not immediately clear which of these is better. If
-<tt>D::operator()</tt> is a template function similar to <tt>shared_ptr</tt>'s
-constructor, then <tt>d(static_cast&lt;T*&gt;(0))</tt> will compile and <tt>d(nullptr)</tt>
-will not. On the other hand, if <tt>D::operator()()</tt> takes a parameter that
-is a pointer to some type other that <tt>T</tt> (for instance <tt>U*</tt> where <tt>U</tt> derives
-from <tt>T</tt>) then <tt>d(nullptr)</tt> will compile and <tt>d(static_cast&lt;T *&gt;(0))</tt> may not.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-The general idea is right, we need to be able to pass a nullptr to a
-shared_ptr, but there are a few borderline editorial issues here. (For
-example, the single-argument nullptr_t constructor in the class synopsis
-isn't marked explicit, but it is marked explicit in the proposed wording
-for 20.6.6.2.1. There is a missing empty parenthesis in the form that
-takes a nullptr_t, a deleter, and an allocator.)
-</p>
-<p>
-More seriously: this issue says that a shared_ptr constructed from a
-nullptr is empty. Since "empty" is undefined, it's hard to know whether
-that's right. This issue is pending on handling that term better.
-</p>
-<p>
-Peter suggests definition of empty should be "does not own anything"
-</p>
-<p>
-Is there an editorial issue that post-conditions should refer to get() =
-nullptr, rather than get() = 0?
-</p>
-<p>
-No strong feeling towards accept or NAD, but prefer to make a decision than leave it open.
-</p>
-<p>
-Seems there are no technical merits between NAD and Ready, comes down to
-"Do we intentially want to allow/disallow null pointers with these
-functions". Staw Poll - support null pointers 5 - No null pointers 0
-</p>
-<p>
-Move to Ready, modulo editorial comments
-</p>
-</blockquote>
-
-<p><i>[
-post Bellevue Peter adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-The following wording changes are less intrusive:
-</p>
-
-<p>
-In 20.7.12.2.1 [util.smartptr.shared.const], add:
-</p>
-
-<blockquote><pre>shared_ptr(nullptr_t);
-</pre></blockquote>
-
-<p>
-after:
-</p>
-
-<blockquote><pre>shared_ptr();
-</pre></blockquote>
-
-<p>
-(Absence of explicit intentional.)
-</p>
-
-<p>
-<tt>px.reset( nullptr )</tt> seems a somewhat contrived way to write <tt>px.reset()</tt>, so
-I'm not convinced of its utility.
-</p>
-<p>
-It's similarly not clear to me whether the deleter constructors need to be
-extended to take <tt>nullptr</tt>, but if they need to:
-</p>
-<p>
-Add
-</p>
-
-<blockquote><pre>template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
-template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
-</pre></blockquote>
-
-<p>
-after
-</p>
-
-<blockquote><pre>template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
-template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
-</pre></blockquote>
-
-<p>
-Note that this changes the semantics of the new constructors such that they
-consistently call <tt>d(p)</tt> instead of <tt>d((T*)0)</tt> when <tt>p</tt> is <tt>nullptr</tt>.
-</p>
-<p>
-The ability to be able to pass <tt>0/NULL</tt> to a function that takes a <tt>shared_ptr</tt>
-has repeatedly been requested by users, but the other additions that the
-proposed resolution makes are not supported by real world demand or
-motivating examples.
-</p>
-<p>
-It might be useful to split the obvious and non-controversial <tt>nullptr_t</tt>
-constructor into a separate issue. Waiting for "empty" to be clarified is
-unnecessary; this is effectively an alias for the default constructor.
-</p>
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-We want to remove the reset functions from the proposed resolution.
-</p>
-<p>
-The remaining proposed resolution text (addressing the constructors) are wanted.
-</p>
-<p>
-Disposition: move to review. The review should check the wording in the then-current working draft.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following constructors to 20.7.12.2 [util.smartptr.shared]:
-</p>
-
-<blockquote><pre>shared_ptr(nullptr_t);
-template &lt;class D&gt; shared_ptr(nullptr_t, D d);
-template &lt;class D, class A&gt; shared_ptr(nullptr_t, D d, A a);
-</pre></blockquote>
-
-
-
-<p>
-Add the following constructor definitions to 20.7.12.2.1 [util.smartptr.shared.const]:
-</p>
-
-<blockquote>
-<pre> explicit shared_ptr(nullptr_t);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an empty shared_ptr object.
-</p>
-<p>
-<i>Postconditions:</i> <tt>use_count() == 0 &amp;&amp; get() == 0</tt>.
-</p>
-<p>
-<i>Throws:</i> nothing.
-</p>
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>template &lt;class D&gt; shared_ptr(nullptr_t, D d);
-template &lt;class D, class A&gt; shared_ptr&lt;nullptr_t, D d, A a);
-</pre>
-<blockquote>
-<p>
-<i>Requires:</i> <tt>D</tt> shall be <tt>CopyConstructible</tt>. The copy constructor and
-destructor of <tt>D</tt> shall not throw exceptions. The expression
-<tt>d(static_cast&lt;T *&gt;(0))</tt> shall be well-formed, shall have well defined behavior,
-and shall not throw exceptions. <tt>A</tt> shall be an allocator (20.1.2 [allocator.requirements]).
-The copy constructor and destructor of <tt>A</tt> shall not throw
-exceptions.
-</p>
-<p>
-<i>Effects:</i> Constructs a <tt>shared_ptr</tt> object that owns a null pointer of type <tt>T *</tt>
-and deleter <tt>d</tt>. The
-second constructor shall use a copy of <tt>a</tt> to allocate memory for
-internal use.
-</p>
-<p>
-<i>Postconditions:</i> <tt>use_count() == 1</tt> and <tt>get() == 0</tt>.
-</p>
-<p>
-<i>Throws:</i> <tt>bad_alloc</tt>, or an implementation-defined exception when a
-resource other than memory could not be obtained.
-</p>
-<p>
-<i>Exception safety:</i> If an exception is thrown, <tt>d(static_cast&lt;Y *&gt;(nullptr))</tt> is called.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="760"></a>760. The emplace issue</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-11-11</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In an emplace member function the function parameter pack may be bound
-to a priori unlimited number of objects: some or all of them can be
-elements of the container itself. Apparently, in order to conform to the
-blanket statement 23.1 [container.requirements]/11, the implementation must check all of them for
-that possibility. A possible solution can involve extending the
-exception in 23.1 [container.requirements]/12 also to the emplace member. As a side note, the
-<tt>push_back</tt> and <tt>push_front</tt> member functions are luckily not affected by
-this problem, can be efficiently implemented anyway
-</p>
-
-<p><i>[
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
-]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-The proposed addition (13) is partially redundant with the existing
-paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why
-does it not cover subelements and pointers?
-</p>
-<p>
-Resolution: Alan Talbot to rework language, then set state to Review.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add after 23.1 [container.requirements]/12:
-</p>
-
-<blockquote>
-<p>
--12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No
-diagnostic required.
-</p>
-<p>
-<ins>
--13- Objects bound to the function parameter pack of the <tt>emplace</tt> member function shall not be elements or
-sub-objects of elements of the container. No diagnostic required.
-</ins>
-</p>
-
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="762"></a>762. <tt>std::unique_ptr</tt> requires complete type?</h3>
-<p><b>Section:</b> 20.7.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-11-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In contrast to the proposed <tt>std::shared_ptr</tt>, <tt>std::unique_ptr</tt>
-does currently not support incomplete types, because it
-gives no explicit grant - thus instantiating <tt>unique_ptr</tt> with
-an incomplete pointee type <tt>T</tt> automatically belongs to
-undefined behaviour according to 17.4.3.7 [res.on.functions]/2, last
-bullet. This is an unnecessary restriction and prevents
-many well-established patterns - like the bridge pattern -
-for <tt>std::unique_ptr</tt>.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Move to open. The LWG is comfortable with the intent of allowing
-incomplete types and making <tt>unique_ptr</tt> more like <tt>shared_ptr</tt>, but we are
-not comfortable with the wording. The specification for <tt>unique_ptr</tt>
-should be more like that of <tt>shared_ptr</tt>. We need to know, for individual
-member functions, which ones require their types to be complete. The
-<tt>shared_ptr</tt> specification is careful to say that for each function, and
-we need the same level of care here. We also aren't comfortable with the
-"part of the operational semantic" language; it's not used elsewhere in
-the standard, and it's not clear what it means. We need a volunteer to
-produce new wording.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-The proposed changes in the following revision refers to the current state of
-N2521 including the assumption that 20.7.11.4 [unique.ptr.compiletime] will be removed
-according to the current state of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>.
-</p>
-<p>
-The specialization <tt>unique_ptr&lt;T[]&gt;</tt> has some more restrictive constraints on
-type-completeness on <tt>T</tt> than <tt>unique_ptr&lt;T&gt;</tt>. The following proposed wordings
-try to cope with that. If the committee sees less usefulness on relaxed
-constraints on <tt>unique_ptr&lt;T[]&gt;</tt>, the alternative would be to stop this relaxation
-e.g. by adding one further bullet to 20.7.11.3 [unique.ptr.runtime]/1:
-"<tt>T</tt> shall be a complete type, if used as template argument of
-<tt>unique_ptr&lt;T[], D&gt;</tt>
-</p>
-<p>
-This issue has some overlap with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, but it seems not to cause any
-problems with this one,
-because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> adds only optional requirements on <tt>D</tt> that do not conflict
-with the here discussed
-ones, provided that <tt>D::pointer</tt>'s operations (including default
-construction, copy construction/assignment,
-and pointer conversion) are specified <em>not</em> to throw, otherwise this
-would have impact on the
-current specification of <tt>unique_ptr</tt>.
-</p>
-
-<ol>
-<li>
-<p>
-In 20.7.11 [unique.ptr]/2 add as the last sentence to the existing para:
-</p>
-
-<blockquote>
-The <tt>unique_ptr</tt> provides a semantics of strict ownership. A
-<tt>unique_ptr</tt> owns the object it holds a pointer to. A
-<tt>unique_ptr</tt> is not <tt>CopyConstructible</tt>, nor
-<tt>CopyAssignable</tt>, however it is <tt>MoveConstructible</tt> and
-<tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of
-<tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The
-uses of <tt>unique_ptr</tt> include providing exception safety for
-dynamically allcoated memory, passing ownership of dynamically allocated
-memory to a function, and returning dynamically allocated memory from a
-function. -- <i>end note</i> ]
-</blockquote>
-</li>
-
-<li>
-<p>
-20.7.11.2.1 [unique.ptr.single.ctor]/1: No changes necessary.
-</p>
-
-<blockquote>
-<p><i>[
-N.B.: We only need the requirement that <tt>D</tt> is <tt>DefaultConstructible</tt>.
-The current wording says just this.
-]</i></p>
-
-</blockquote>
-</li>
-
-<li>
-<p>
-In 20.7.11.2.1 [unique.ptr.single.ctor]/5 change the requires clause to say:
-</p>
-
-<blockquote>
-<p>
-<i>Requires:</i> <del>The expression <tt>D()(p)</tt> shall be well formed. The default constructor
-of <tt>D</tt> shall not throw an exception.</del>
-<del><tt>D</tt> must not be a reference type.</del>
-<ins>
-<tt>D</tt> shall be default constructible, and that construction
-shall not throw an exception.
-</ins>
-</p>
-<p><i>[
-N.B.: There is no need that the expression <tt>D()(p)</tt> is well-formed at
-this point. I assume that the current wording is based on the
-corresponding <tt>shared_ptr</tt> wording. In case of <tt>shared_ptr</tt> this
-requirement is necessary, because the corresponding c'tor *can* fail
-and must invoke delete <tt>p/d(p)</tt> in this case. <tt>Unique_ptr</tt> is simpler in
-this regard. The *only* functions that must insist on well-formedness
-and well-definedness of the expression <tt>get_deleter()(get())</tt> are (1)
-the destructor and (2) <tt>reset</tt>. The reasoning for the wording change to
-explicitly require <tt>DefaultConstructible</tt> of <tt>D</tt> is to guarantee that
-invocation of
-<tt>D</tt>'s default c'tor is both well-formed and well-defined. Note also that
-we do *not* need the
-requirement that <tt>T</tt> must be complete, also in contrast to <tt>shared_ptr</tt>.
-<tt>Shared_ptr</tt> needs this, because it's c'tor is a template c'tor which
-potentially requires <tt>Convertible&lt;Y*, X*&gt;</tt>, which
-again requires Completeness of <tt>Y</tt>, if <tt>!SameType&lt;X, Y&gt;</tt>
-]</i></p>
-
-</blockquote>
-</li>
-
-<li>
-<p>
-Merge 20.7.11.2.1 [unique.ptr.single.ctor]/12+13 thereby removing the sentence
-of 12, but transferring the "requires" to 13:
-</p>
-
-<blockquote>
-<p>
-<i>Requires:</i> If <tt>D</tt> is not an lvalue-reference type then[..]
-</p>
-<p><i>[
-N.B.: For the same reasons as for (3), there is no need that <tt>d(p)</tt> is
-well-formed/well-defined at this point. The current wording guarantees
-all what we need, namely that the initialization of both the <tt>T*</tt>
-pointer and the <tt>D</tt> deleter are well-formed and well-defined.
-]</i></p>
-
-</blockquote>
-</li>
-
-<li>
-20.7.11.2.1 [unique.ptr.single.ctor]/17: No changes necessary.
-</li>
-<li>
-<p>20.7.11.2.1 [unique.ptr.single.ctor]/21:</p>
-
-<blockquote>
-<i>Requires:</i> If <tt>D</tt> is not a reference type, construction of
-the deleter <tt>D</tt> from an rvalue of type <tt>E</tt> shall be well
-formed and shall not throw an exception. If <tt>D</tt> is a reference
-type, then <tt>E</tt> shall be the same type as <tt>D</tt> (diagnostic
-required). <tt>U*</tt> shall be implicitly convertible to <tt>T*</tt>.
-<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
-be complete types. <i>-- end note</i>]</ins>
-</blockquote>
-
-<p><i>[
-N.B.: The current wording of 21 already implicitly guarantees that <tt>U</tt>
-is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt> is
-true. If the committee wishes this explicit requirement can be added,
-e.g. "<tt>U</tt> shall be a complete type."
-]</i></p>
-
-</li>
-
-<li>
-<p>
-20.7.11.2.2 [unique.ptr.single.dtor]: Just before p1 add a new paragraph:
-</p>
-<blockquote>
-<p>
-<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
-shall have well-defined behavior, and shall not throw exceptions.
-<ins>[<i>Note:</i> The use of <tt>default_delete</tt> requires <tt>T</tt> to
-be a complete type. <i>-- end note</i>]</ins>
-</p>
-<p><i>[
-N.B.: This requirement ensures that the whole responsibility on
-type-completeness of <tt>T</tt> is delegated to this expression.
-]</i></p>
-
-</blockquote>
-</li>
-
-<li>
-<p>
-20.7.11.2.3 [unique.ptr.single.asgn]/1: No changes necessary, except the
-current editorial issue, that "must shall" has to be changed to
-"shall", but this change is not a special part of this resolution.
-</p>
-
-<p><i>[
-N.B. The current wording is sufficient, because we can delegate all
-further requirements on the requirements of the effects clause
-]</i></p>
-
-</li>
-
-<li>
-<p>
-20.7.11.2.3 [unique.ptr.single.asgn]/6:
-</p>
-
-<blockquote>
-<i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
-<tt>D</tt> shall not throw an exception. <tt>U*</tt> shall be implicitly
-convertible to <tt>T*</tt>.
-<ins>[<i>Note:</i> These requirements imply that <tt>T</tt> and <tt>U</tt>
-be complete types. <i>-- end note</i>]</ins>
-</blockquote>
-
-<p><i>[
-N.B.: The current wording of p. 6 already implicitly guarantees that
-<tt>U</tt> is completely defined, because it requires that <tt>Convertible&lt;U*, T*&gt;</tt>
-is true, see (6)+(8).
-]</i></p>
-
-</li>
-
-<li>
-<p>
-20.7.11.2.3 [unique.ptr.single.asgn]/11: No changes necessary.
-</p>
-<p><i>[
-N.B.: Delegation to requirements of effects clause is sufficient.
-]</i></p>
-
-</li>
-
-<li>
-20.7.11.2.4 [unique.ptr.single.observers]/1+4+7+9+11:
-</li>
-
-<blockquote>
-<pre>T* operator-&gt;() const;</pre>
-<blockquote>
-<ins><i>Note:</i> Use typically requires <tt>T</tt> shall be complete. <i>-- end note</i>]</ins>
-</blockquote>
-</blockquote>
-
-<li>
-20.7.11.2.5 [unique.ptr.single.modifiers]/1: No changes necessary.
-</li>
-
-<li>
-<p>
-20.7.11.2.5 [unique.ptr.single.modifiers]/4: Just before p. 4 add a new paragraph:
-</p>
-<blockquote>
-<i>Requires:</i> The expression <tt>get_deleter()(get())</tt> shall be well-formed,
-shall have well-defined behavior, and shall not throw exceptions.
-</blockquote>
-</li>
-
-<li>
-20.7.11.2.5 [unique.ptr.single.modifiers]/7: No changes necessary.
-</li>
-
-<li>
-<p>
-20.7.11.3 [unique.ptr.runtime]: Add one additional bullet on paragraph 1:
-</p>
-
-<blockquote>
-<p>
-A specialization for array types is provided with a slightly altered interface.
-</p>
-
-<ul>
-<li>
-...
-</li>
-<li>
-<ins><tt>T</tt> shall be a complete type.</ins>
-</li>
-</ul>
-</blockquote>
-</li>
-</ol>
-
-<p><i>[
-post Bellevue: Daniel provided revised wording.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="765"></a>765. more on iterator validity</h3>
-<p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-12-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>
-defines the meaning of the term "invalid iterator" as one that may be
-singular.
-
- </p>
- <p>
-
-Consider the following code:
-
- </p>
- <pre> std::deque&lt;int&gt; x, y;
- std::deque&lt;int&gt;::iterator i = x.end(), j = y.end();
- x.swap(y);
- </pre>
- <p>
-
-Given that <code>swap()</code> is required not to invalidate iterators
-and using the definition above, what should be the expected result of
-comparing <code>i</code> and <code>j</code> to <code>x.end()</code>
-and <code>y.end()</code>, respectively, after the <code>swap()</code>?
-
- </p>
- <p>
-
-I.e., is the expression below required to evaluate
-to <code>true</code>?
-
- </p>
- <pre> i == y.end() &amp;&amp; j == x.end()
- </pre>
- <p>
-
-(There are at least two implementations where the expression
-returns <code>false</code>.)
-
- </p>
- <p>
-
-More generally, is the definition introduced in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a> meant to
-make any guarantees about whether iterators actually point to the same
-elements or be associated with the same containers after a
-non-invalidating operation as they did before?
-
- </p>
- <p>
-
-Here's a motivating example intended to demonstrate the importance of
-the question:
-
- </p>
- <pre> Container x, y ({ 1, 2}); // pseudocode to initialize y with { 1, 2 }
- Container::iterator i = y.begin() + 1;
- Container::iterator j = y.end();
- std::swap(x, y);
- std::find(i, j, 3);
- </pre>
- <p>
-
-<code>swap()</code> guarantees that <code>i</code> and <code>j</code>
-continue to be valid. Unless the spec says that even though they are
-valid they may no longer denote a valid range the code above must be
-well-defined. Expert opinions on this differ as does the behavior of
-popular implementations for some standard <code>Containers</code>.
-
- </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="769"></a>769. std::function should use nullptr_t instead of "unspecified-null-pointer-type"</h3>
-<p><b>Section:</b> 20.6.15.2 [func.wrap.func] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-01-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-N2461 already replaced in 20.6.15.2 [func.wrap.func] it's originally proposed
-(implicit) conversion operator to "unspecified-bool-type" by the new
-explicit bool conversion, but the inverse conversion should also
-use the new <tt>std::nullptr_t</tt> type instead of "unspecified-null-pointer-
-type".
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-In 20.6 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis replace:
-</p>
-
-<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
- bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template&lt;class R, class... ArgTypes&gt;
- bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
-template&lt;class R, class... ArgTypes&gt;
- bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template&lt;class R, class... ArgTypes&gt;
- bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
-</pre></blockquote>
-
-<p>
-In the class function synopsis of 20.6.15.2 [func.wrap.func] replace
-</p>
-
-<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-...
-function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-</pre></blockquote>
-
-<p>
-In 20.6.15.2 [func.wrap.func], "Null pointer comparisons" replace:
-</p>
-
-<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
- bool operator==(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template &lt;class R, class... ArgTypes&gt;
- bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
-template &lt;class R, class... ArgTypes&gt;
- bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp;, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template &lt;class R, class... ArgTypes&gt;
- bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp;);
-</pre></blockquote>
-
-<p>
-In 20.6.15.2.1 [func.wrap.func.con], replace
-</p>
-
-<blockquote><pre>function(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-...
-function&amp; operator=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-</pre></blockquote>
-
-<p>
-In 20.6.15.2.6 [func.wrap.func.nullptr], replace
-</p>
-
-<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
- bool operator==(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template &lt;class R, class... ArgTypes&gt;
- bool operator==(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
-</pre></blockquote>
-
-<p>
-and replace
-</p>
-
-<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
- bool operator!=(const function&lt;R(ArgTypes...)&gt;&amp; f, <del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins>);
-template &lt;class R, class... ArgTypes&gt;
- bool operator!=(<del>unspecified-null-pointer-type</del> <ins>nullptr_t</ins> , const function&lt;R(ArgTypes...)&gt;&amp; f);
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="771"></a>771. Impossible throws clause in [string.conversions]</h3>
-<p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-01-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The new <tt>to_string</tt> and <tt>to_wstring</tt> functions described in 21.4 [string.conversions]
-have throws clauses (paragraphs 8 and 16) which say:
-</p>
-
-<blockquote>
-<i>Throws:</i> nothing
-</blockquote>
-
-<p>
-Since all overloads return either a <tt>std::string</tt> or a <tt>std::wstring</tt> by value
-this throws clause is impossible to realize in general, since the <tt>basic_string</tt>
-constructors can fail due to out-of-memory conditions. Either these throws
-clauses should be removed or should be more detailled like:
-</p>
-
-<blockquote>
-<i>Throws:</i> Nothing if the string construction throws nothing
-</blockquote>
-
-<p>
-Further there is an editorial issue in p. 14: All three <tt>to_wstring</tt>
-overloads return a <tt>string</tt>, which should be <tt>wstring</tt> instead (The
-header <tt>&lt;string&gt;</tt> synopsis of 21.2 [string.classes] is correct in this
-regard).
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 21.4 [string.conversions], remove the paragraphs 8 and 16.
-</p>
-
-<blockquote>
-<pre>string to_string(long long val);
-string to_string(unsigned long long val);
-string to_string(long double val);
-</pre>
-<blockquote>
-<del><i>Throws:</i> nothing</del>
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre><ins>w</ins>string to_wstring(long long val);
-<ins>w</ins>string to_wstring(unsigned long long val);
-<ins>w</ins>string to_wstring(long double val);
-</pre>
-<blockquote>
-<del><i>Throws:</i> nothing</del>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="772"></a>772. Impossible return clause in [string.conversions]</h3>
-<p><b>Section:</b> 21.4 [string.conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-01-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#string.conversions">active issues</a> in [string.conversions].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.conversions">issues</a> in [string.conversions].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The return clause 21.4 [string.conversions]/paragraph 15 of the new <tt>to_wstring</tt>
-overloads says:
-</p>
-
-<blockquote>
-<i>Returns:</i> each function returns a <tt>wstring</tt> object holding the character
-representation of the value of its argument that would be generated by
-calling <tt>wsprintf(buf, fmt, val)</tt> with a format specifier of <tt>L"%lld"</tt>, <tt>L"%ulld"</tt>,
-or <tt>L"%f"</tt>, respectively.
-</blockquote>
-
-<p>
-Problem is: There does not exist any <tt>wsprintf</tt> function in C99 (I checked
-the 2nd edition of ISO 9899, and the first and the second corrigenda from
-2001-09-01 and 2004-11-15). What probably meant here is the function
-<tt>swprintf</tt> from <tt>&lt;wchar.h&gt;/&lt;cwchar&gt;</tt>, but this has the non-equivalent
-declaration:
-</p>
-
-<blockquote><pre>int swprintf(wchar_t * restrict s, size_t n,
-const wchar_t * restrict format, ...);
-</pre></blockquote>
-
-<p>
-therefore the paragraph needs to mention the <tt>size_t</tt> parameter <tt>n</tt>.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the current wording of 21.4 [string.conversions]/p. 15 to:
-</p>
-
-<blockquote>
-<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a
-<tt>wstring</tt> object holding the character representation of the
-value of its argument that would be generated by calling
-<tt><del>ws</del><ins>sw</ins>printf(buf, <ins>bufsz,</ins> fmt,
-val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of <tt>L"%lld"</tt>,
-<tt>L"%ulld"</tt>, or <tt>L"%f"</tt>, respectively<ins>, where <tt>buf</tt>
-designates an internal character buffer of sufficient size <tt>bufsz</tt></ins>.
-</blockquote>
-
-<p>
-[Hint to the editor: The resolution also adds to mention the name of
-the format specifier "fmt"]
-</p>
-
-<p>
-I also would like to remark that the current wording of it's equivalent
-paragraph 7 should also mention the meaning of <tt>buf</tt> and <tt>fmt</tt>.
-</p>
-
-<p>
-Change the current wording of 21.4 [string.conversions]/p. 7 to:
-</p>
-
-<blockquote>
-<i>Returns:</i> <del>e</del><ins>E</ins>ach function returns a string object holding the
-character representation of the value of its argument that would be
-generated by calling <tt>sprintf(buf, fmt, val)</tt> with a format specifier <ins><tt>fmt</tt></ins> of
-<tt>"%lld"</tt>, <tt>"%ulld"</tt>, or <tt>"%f"</tt>, respectively<ins>, where <tt>buf</tt> designates an internal
-character buffer of sufficient size</ins>.
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="774"></a>774. Member swap undefined for most containers</h3>
-<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It appears most containers declare but do not define a member-swap
-function.
-</p>
-
-<p>
-This is unfortunate, as all overload the <tt>swap</tt> algorithm to call the
-member-swap function!
-(required for <tt>swappable</tt> guarantees [Table 37] and Container Requirements
-[Table 87])
-</p>
-
-<p>
-Note in particular that Table 87 gives semantics of <tt>a.swap(b)</tt> as <tt>swap(a,b)</tt>,
-yet for all containers we define <tt>swap(a,b)</tt> to call <tt>a.swap(b)</tt> - a circular
-definition.
-</p>
-
-<p>
-A quick survey of clause 23 shows that the following containers provide a
-definition for member-swap:
-</p>
-
-<blockquote><pre>array
-queue
-stack
-vector
-</pre></blockquote>
-
-<p>
-Whereas the following declare it, but do not define the semantics:
-</p>
-
-<blockquote><pre>deque
-list
-map
-multimap
-multiset
-priority_queue
-set
-unordered_map
-unordered_multi_map
-unordered_multi_set
-unordered_set
-</pre></blockquote>
-
-<p>
-Suggested resolution:
-</p>
-<blockquote>
-Provide a definition for each of the affected containers...
-</blockquote>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Move to Open and ask Alisdair to provide wording.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Wording provided in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2590.pdf">N2590</a>.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="776"></a>776. Undescribed assign function of std::array</h3>
-<p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-01-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The class template array synopsis in 23.2.1 [array]/3 declares a member
-function
-</p>
-
-<blockquote><pre>void assign(const T&amp; u);
-</pre></blockquote>
-
-<p>
-which's semantic is no-where described. Since this signature is
-not part of the container requirements, such a semantic cannot
-be derived by those.
-</p>
-
-<p>
-I found only one reference to this function in the issue list,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a> where the question is raised:
-</p>
-
-<blockquote>
-what's the effect of calling <tt>assign(T&amp;)</tt> on a zero-sized array?
-</blockquote>
-
-<p>
-which does not answer the basic question of this issue.
-</p>
-
-<p>
-If this function shall be part of the <tt>std::array</tt>, it's probable
-semantic should correspond to that of <tt>boost::array</tt>, but of
-course such wording must be added.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Just after the section 23.2.1.4 [array.data] add the following new section:
-</p>
-
-<p>
-23.2.1.5 array::fill [array.fill]
-</p>
-
-<blockquote>
-<pre>void fill(const T&amp; u);
-</pre>
-
-<p>
-1: <i>Effects:</i> <tt>fill_n(begin(), N, u)</tt>
-</p>
-</blockquote>
-
-<p>
-[N.B: I wonder, why class <tt>array</tt> does not have a "modifiers"
-section. If it had, then <tt>assign</tt> would naturally belong to it]
-</p>
-
-<p>
-Change the synopsis in 23.2.1 [array]/3:
-</p>
-
-<blockquote><pre>template &lt;class T, size_t N&gt;
-struct array {
- ...
- void <del>assign</del> <ins>fill</ins>(const T&amp; u);
- ...
-</pre></blockquote>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Suggest substituting "fill" instead of "assign".
-</p>
-<p>
-Set state to Review given substitution of "fill" for "assign".
-</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="779"></a>779. Resolution of #283 incomplete</h3>
-<p><b>Section:</b> 25.2.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-01-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> did not resolve similar necessary changes for algorithm
-<tt>remove_copy[_if]</tt>,
-which seems to be an oversight.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 25.2.8 [alg.remove]/p.6, replace the N2461 requires clause with:
-</p>
-
-<blockquote>
-<i>Requires:</i> <del>Type <tt>T</tt> is <tt>EqualityComparable</tt> (31).</del> The ranges <tt>[first,last)</tt>
-and <tt>[result,result + (last - first))</tt> shall not overlap. <ins>The expression <tt>*result = *first</tt> shall be
-valid.</ins>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="780"></a>780. <tt>std::merge()</tt> specification incorrect/insufficient</h3>
-<p><b>Section:</b> 25.3.4 [alg.merge] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-01-25</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Though issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a> has fixed many open issues, it seems that some are still open:
-</p>
-
-<p>
-Both 25.3.4 [lib.alg.merge] in 14882:2003 and 25.3.4 [alg.merge] in N2461
-have no Requires element and the Effects element contains some requirements,
-which is probably editorial. Worse is that:
-</p>
-
-<ul>
-<li>
-no assignment requirements are specified (neither implicit nor explicit).
-</li>
-
-<li>
-the effects clause just speaks of "merges", which is badly worded
-near to a circular definition.
-</li>
-
-<li>
-p. 2 mentions a range <tt>[first, last)</tt>, which is not defined by the
-function arguments or otherwise.
-</li>
-
-<li>
-p. 2 says "according to the ordering defined by comp" which is both
-incomplete (because
-this excludes the first variant with &lt;) and redundant (because the
-following subordinate
-clause mentions comp again)
-</li>
-</ul>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 25.3.4 [alg.merge] replace p.1+ 2:
-</p>
-
-<blockquote>
-<p>
-<i>Effects:</i> <del>Merges</del> <ins>Copies all the elements of the</ins> two sorted ranges <tt>[first1,last1)</tt> and
-<tt>[first2,last2)</tt> into the range
-<del><tt>[result,result + (last1 - first1) + (last2 - first2))</tt></del>
-<ins><tt>[result, last)</tt> (where <tt>last</tt> is equal to <tt>result + (last1
-- first1) + (last2 - first2))</tt>, such that resulting range will be
-sorted in non-decreasing order; that is, for every iterator <tt>i</tt> in
-<tt>[result,last)</tt> other than <tt>result</tt>, the condition <tt>*i &lt; *(i - 1)</tt> or,
-respectively, <tt>comp(*i, *(i - 1))</tt> will be false</ins>.
-</p>
-
-<p>
-<ins><i>Requires:</i></ins> The resulting range shall not overlap with either of the original ranges. <del>The list will be sorted in non-decreasing
-order according to the ordering defined by <tt>comp</tt>; that is, for every iterator <tt>i</tt> in
-<tt>[first,last)</tt> other than <tt>first</tt>, the condition <tt>*i &lt; *(i - 1)</tt> or
-<tt>comp(*i, *(i - 1))</tt> will be false.</del> <ins>The results of the expressions <tt>*first1</tt> and <tt>*first2</tt>
-shall be writable to the output iterator.</ins>
-</p>
-</blockquote>
-
-<p>
-[N.B.: I attempted to reuse the wording style of <tt>inplace_merge</tt>,
-therefore proposing to
-insert ", respectively," between both predicate tests. This is no
-strictly necessary as
-other parts of <tt>&lt;algorithm&gt;</tt> show, just a matter of consistency]
-</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="785"></a>785. Random Number Requirements in TR1</h3>
-<p><b>Section:</b> TR1 5.1.4.5 [tr.rand.eng.disc], TR1 5.1.4.6 [tr.rand.eng.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> John Maddock <b>Date:</b> 2008-01-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Table 16 of TR1 requires that all Pseudo Random Number generators have a
-</p>
-
-<blockquote><pre>seed(integer-type s)
-</pre></blockquote>
-
-<p>
-member function that is equivalent to:
-</p>
-
-<blockquote><pre>mygen = Generator(s)
-</pre></blockquote>
-
-<p>
-But the generators <tt>xor_combine</tt> and <tt>discard_block</tt> have no such seed member, only the
-</p>
-
-<blockquote><pre>template &lt;class Gen&gt;
-seed(Gen&amp;);
-</pre></blockquote>
-
-<p>
-member, which will not accept an integer literal as an argument: something that appears to violate the intent of Table 16.
-</p>
-
-<p>
-So... is this a bug in TR1?
-</p>
-
-<p>This is a real issue BTW, since the Boost implementation does adhere
-to the requirements of Table 16, while at least one commercial
-implementation does not and follows a strict adherence to sections
-5.1.4.5 and 5.1.4.6 instead.
-</p>
-
-<p><i>[
-Jens adds:
-]</i></p>
-
-
-<blockquote>
-Both engines do have the necessary
-constructor, therefore the omission of the <tt>seed()</tt> member
-functions appears to be an oversight.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="787"></a>787. complexity of <tt>binary_search</tt></h3>
-<p><b>Section:</b> 25.3.3.4 [binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-09-08</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 25.3.3.4 [binary.search]/3 the complexity of <tt>binary_search</tt> is described as
-</p>
-
-<blockquote>
-At most <tt>log(last - first) + 2</tt> comparisons.
-</blockquote>
-
-<p>
-This should be precised and brought in line with the nomenclature used for
-<tt>lower_bound</tt>, <tt>upper_bound</tt>, and <tt>equal_range</tt>.
-</p>
-
-<p>
-All existing libraries I'm aware of, delegate to
-<tt>lower_bound</tt> (+ one further comparison). Since
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>
-has now WP status, the resolution of #787 should
-be brought in-line with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a> by changing the <tt>+ 2</tt>
-to <tt>+ O(1)</tt>.
-</p>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-Alisdair prefers to apply an upper bound instead of O(1), but that would
-require fixing for <tt>lower_bound</tt>, <tt>upper_bound</tt> etc. as well. If he really
-cares about it, he'll send an issue to Howard.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 25.3.3.4 [binary.search]/3
-</p>
-
-<blockquote>
-<i>Complexity:</i> At most <tt>log<ins><sub>2</sub></ins>(last - first) + <del>2</del> <ins><i>O</i>(1)</ins></tt> comparisons.
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="788"></a>788. ambiguity in [istream.iterator]</h3>
-<p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-02-06</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The description of how an istream_iterator object becomes an
-end-of-stream iterator is a) ambiguous and b) out of date WRT
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>:
-</p>
-
-<blockquote>
-<tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
-input stream for which it was constructed. After it is constructed, and
-every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
-the end of stream is reached (<tt>operator void*()</tt> on the stream returns
-<tt>false</tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
-The constructor with no arguments <tt>istream_iterator()</tt> always constructs
-an end of stream input iterator object, which is the only legitimate
-iterator to be used for the end condition. The result of <tt>operator*</tt> on an
-end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
-returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
-For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
-store things into istream iterators. The main peculiarity of the istream
-iterators is the fact that <tt>++</tt> operators are not equality preserving,
-that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
-is used a new value is read.
-</blockquote>
-
-<p>
-<tt>istream::operator void*()</tt> returns null if <tt>istream::fail()</tt> is <tt>true</tt>,
-otherwise non-null. <tt>istream::fail()</tt> returns <tt>true</tt> if <tt>failbit</tt> or
-<tt>badbit</tt> is set in <tt>rdstate()</tt>. Reaching the end of stream doesn't
-necessarily imply that <tt>failbit</tt> or <tt>badbit</tt> is set (e.g., after
-extracting an <tt>int</tt> from <tt>stringstream("123")</tt> the stream object will
-have reached the end of stream but <tt>fail()</tt> is <tt>false</tt> and <tt>operator
-void*()</tt> will return a non-null value).
-</p>
-
-<p>
-Also I would prefer to be explicit about calling <tt>fail()</tt> here
-(there is no <tt>operator void*()</tt> anymore.)
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 24.5.1 [istream.iterator]/1:
-</p>
-
-<blockquote>
-<tt>istream_iterator</tt> reads (using <tt>operator&gt;&gt;</tt>) successive elements from the
-input stream for which it was constructed. After it is constructed, and
-every time <tt>++</tt> is used, the iterator reads and stores a value of <tt>T</tt>. If
-<del>the end of stream is reached</del> <ins>the iterator fails to read and store a value of <tt>T</tt></ins>
-(<tt><del>operator void*()</del> <ins>fail()</ins></tt> on the stream returns
-<tt><del>false</del> <ins>true</ins></tt>), the iterator becomes equal to the <i>end-of-stream</i> iterator value.
-The constructor with no arguments <tt>istream_iterator()</tt> always constructs
-an end of stream input iterator object, which is the only legitimate
-iterator to be used for the end condition. The result of <tt>operator*</tt> on an
-end of stream is not defined. For any other iterator value a <tt>const T&amp;</tt> is
-returned. The result of <tt>operator-&gt;</tt> on an end of stream is not defined.
-For any other iterator value a <tt>const T*</tt> is returned. It is impossible to
-store things into istream iterators. The main peculiarity of the istream
-iterators is the fact that <tt>++</tt> operators are not equality preserving,
-that is, <tt>i == j</tt> does not guarantee at all that <tt>++i == ++j</tt>. Every time <tt>++</tt>
-is used a new value is read.
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="793"></a>793. <tt>discrete_distribution</tt> missing constructor</h3>
-<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>discrete_distribution</tt> should have a constructor like:
-</p>
-
-<blockquote><pre>template&lt;class _Fn&gt;
- discrete_distribution(result_type _Count, double _Low, double _High,
- _Fn&amp; _Func);
-</pre></blockquote>
-
-<p>
-(Makes it easier to fill a histogram with function values over a range.)
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-How do you specify the function so that it does not return negative
-values? If you do it is a bad construction. This requirement is already
-there. Where in each bin does one evaluate the function? In the middle.
-Need to revisit tomorrow.
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-Bill is not requesting this.
-</p>
-<p>
-Marc Paterno: <tt>_Fn</tt> cannot return negative values at the points where the
-function is sampled. It is sampled in the middle of each bin. <tt>_Fn</tt> cannot
-return 0 everywhere it is sampled.
-</p>
-<p>
-Jens: lambda expressions are rvalues
-</p>
-<p>
-Add a library issue to provide an
-<tt>initializer_list&lt;double&gt;</tt> constructor for
-<tt>discrete_distribution</tt>.
-</p>
-<p>
-Marc Paterno: dislikes reference for <tt>_Fn</tt> parameter. Make it pass-by-value (to use lambda),
-use <tt>std::ref</tt> to wrap giant-state function objects.
-</p>
-<p>
-Daniel: See <tt>random_shuffle</tt>, pass-by-rvalue-reference.
-</p>
-<p>
-Daniel to draft wording.
-</p>
-</blockquote>
-
-<p><i>[
-Pre San Francisco, Daniel provided wording:
-]</i></p>
-
-
-<blockquote>
-The here proposed changes of the WP refer to the current state of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
-During the Sophia Antipolis meeting two different proposals came up
-regarding the functor argument type, either by value or by rvalue-reference.
-For consistence with existing conventions (state-free algorithms and the
-<tt>general_pdf_distribution</tt> c'tor signature) the author decided to propose a
-function argument that is provided by value. If severe concerns exists that
-stateful functions would be of dominant relevance, it should be possible to
-replace the two occurrences of <tt>Func</tt> by <tt>Func&amp;&amp;</tt> in this proposal as part
-of an editorial process.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>
-In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>, just
-<em>before</em> the member declaration
-</p>
-
-<blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
-</pre></blockquote>
-
-<p>
-insert:
-</p>
-
-
-<blockquote><pre>template&lt;typename Func&gt;
-discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
-</pre></blockquote>
-</li>
-
-<li>
-<p>
-Between p.4 and p.5 insert a series of new paragraphs as part of the
-new member description::
-</p>
-<blockquote><pre>template&lt;typename Func&gt;
-discrete_distribution(result_type nf, double xmin, double xmax, Func fw);
-</pre>
-
-<p>
-<i>Complexity:</i> Exactly nf invocations of fw.
-</p>
-<p>
-<i>Requires:</i>
-</p>
-<ol type="a">
-<li>
-fw shall be callable with one argument of type double, and shall
-return values of a type convertible to double;</li>
-
-<li>If nf &gt; 0, the relation <tt><i>x</i><sub><i>min</i></sub></tt> &lt; <tt><i>x</i><sub><i>max</i></sub></tt> shall hold, and for all sample values
-<tt><i>x</i><sub><i>k</i></sub></tt>, fw(<tt><i>x</i><sub><i>k</i></sub></tt>) shall return a weight value <tt><i>w</i><sub><i>k</i></sub></tt> that is non-negative, non-NaN,
-and non-infinity;</li>
-
-<li>The following relations shall hold: nf &#8805; 0, and 0 &lt; S = <tt><i>w</i><sub><i>0</i></sub></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.</li>
-
-</ol>
-
-<p>
-<i>Effects:</i>
-</p>
-<ol type="a">
-<li>If nf == 0, sets n = 1 and lets the sequence w have length n = 1 and
- consist of the single value <tt><i>w</i><sub><i>0</i></sub></tt> = 1.</li>
-
-<li>
-<p>Otherwise, sets n = nf, deltax = (<tt><i>x</i><sub><i>max</i></sub></tt> - <tt><i>x</i><sub><i>min</i></sub></tt>)/n and <tt><i>x</i><sub><i>cent</i></sub></tt> = <tt><i>x</i><sub><i>min</i></sub></tt> +
-0.5 * deltax.</p>
-<blockquote><pre>For each k = 0, . . . ,n-1, calculates:
- <tt><i>x</i><sub><i>k</i></sub></tt> = <tt><i>x</i><sub><i>cent</i></sub></tt> + k * deltax
- <tt><i>w</i><sub><i>k</i></sub></tt> = fw(<tt><i>x</i><sub><i>k</i></sub></tt>)
-</pre></blockquote>
-</li>
-<li>
-<p>Constructs a discrete_distribution object with probabilities:</p>
-<blockquote><pre><tt><i>p</i><sub><i>k</i></sub></tt> = <tt><i>w</i><sub><i>k</i></sub></tt>/S for k = 0, . . . , n-1.
-</pre></blockquote>
-</li>
-</ol>
-</blockquote>
-</li>
-</ol>
-
-
-
-
-
-<hr>
-<h3><a name="794"></a>794. <tt>piecewise_constant_distribution</tt> missing constructor</h3>
-<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>piecewise_constant_distribution</tt> should have a constructor like:
-</p>
-
-<blockquote><pre>template&lt;class _Fn&gt;
- piecewise_constant_distribution(size_t _Count,
- _Ty _Low, _Ty _High, _Fn&amp; _Func);
-</pre></blockquote>
-
-<p>
-(Makes it easier to fill a histogram with function values over a range.
-The two (reference <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>) make a sensible replacement for
-<tt>general_pdf_distribution</tt>.)
-</p>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-Marc: uses variable width of bins and weight for each bin. This is not
-giving enough flexibility to control both variables.
-</p>
-<p>
-Add a library issue to provide an constructor taking an
-<tt>initializer_list&lt;double&gt;</tt> and <tt>_Fn</tt> for <tt>piecewise_constant_distribution</tt>.
-</p>
-<p>
-Daniel to draft wording.
-</p>
-</blockquote>
-
-<p><i>[
-Pre San Francisco, Daniel provided wording.
-]</i></p>
-
-
-<blockquote>
-The here proposed changes of the WP refer to the current state of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>.
-For reasons explained in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, the author decided to propose a function
-argument that is provided by value. The issue proposes a c'tor signature,
-that does not take advantage of the full flexibility of
-<tt>piecewise_constant_distribution</tt>,
-because it restricts on a constant bin width, but the use-case seems to
-be popular enough to justify it's introduction.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<ol>
-<li>
-<p>
-In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
-just <em>before</em> the member declaration
-</p>
-
-<blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
-</pre></blockquote>
-<p>
-insert:
-</p>
-<blockquote><pre>template&lt;typename Func&gt;
-piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
-</pre></blockquote>
-</li>
-
-<li>
-<p>
-Between p.4 and p.5 insert a new sequence of paragraphs nominated
-below as [p5_1], [p5_2],
-[p5_3], and [p5_4] as part of the new member description:
-</p>
-
-<blockquote><pre>template&lt;typename Func&gt;
-piecewise_constant_distribution(size_t nf, RealType xmin, RealType xmax, Func fw);
-</pre>
-<blockquote>
-<p>
-[p5_1] <i>Complexity:</i> Exactly <tt>nf</tt> invocations of <tt>fw</tt>.
-</p>
-<p>
-[p5_2] <i>Requires:</i>
-</p>
-<ol type="a">
-<li><tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
-return values of a type convertible to double;
-</li>
-<li>
-For all sample values <tt><i>x<sub>k</sub></i></tt> defined below, fw(<tt><i>x<sub>k</sub></i></tt>) shall return a weight
-value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
-</li>
-<li>
-The following relations shall hold: <tt><i>x<sub>min</sub></i></tt> &lt; <tt><i>x<sub>max</sub></i></tt>, and
-0 &lt; S = <tt><i>w<sub>0</sub></i></tt>+. . .+<tt><i>w<sub>n-1</sub></i></tt>.
-</li>
-</ol>
-<p>
-[p5_3] <i>Effects:</i>
-</p>
-<ol type="a">
-<li>
-<p>If nf == 0,</p>
- <ol type="a">
- <li>
-sets deltax = <tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>, and</li>
-<li> lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
- value <tt><i>w<sub>0</sub></i></tt> = 1, and</li>
-<li> lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt><i>b<sub>0</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> and
- <tt><i>b<sub>1</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt>
-</li>
-</ol>
-</li>
-<li>
-<p>Otherwise,</p>
-<ol type="a">
-<li> sets <tt>n = nf</tt>, <tt>deltax = </tt>(<tt><i>x<sub>max</sub></i></tt> - <tt><i>x<sub>min</sub></i></tt>)/n,
- <tt><i>x<sub>cent</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + 0.5 * deltax, and
-</li>
-<li><p>lets the sequences <tt>w</tt> and <tt>b</tt> have length <tt>n</tt> and <tt>n+1</tt>, resp. and</p>
-<blockquote><pre>for each k = 0, . . . ,n-1, calculates:
- <tt><i>dx<sub>k</sub></i></tt> = k * deltax
- <tt><i>b<sub>k</sub></i></tt> = <tt><i>x<sub>min</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
- <tt><i>x<sub>k</sub></i></tt> = <tt><i>x<sub>cent</sub></i></tt> + <tt><i>dx<sub>k</sub></i></tt>
- <tt><i>w<sub>k</sub></i></tt> = fw(<tt><i>x<sub>k</sub></i></tt>),
-</pre></blockquote>
-<p> and</p>
-</li>
-<li> sets <tt><i>b<sub>n</sub></i></tt> = <tt><i>x<sub>max</sub></i></tt></li>
-</ol>
-</li>
-<li>
-<p>
-Constructs a <tt>piecewise_constant_distribution</tt> object with
-the above computed sequence <tt>b</tt> as the interval boundaries
-and with the probability densities:
-</p>
-<blockquote><pre><tt><i>&#961;<sub>k</sub></i></tt> = <tt><i>w<sub>k</sub></i></tt>/(S * deltax) for k = 0, . . . , n-1.
-</pre></blockquote>
-</li>
-</ol>
-<p>
-[p5_4] <i>Remarks:</i> In this context, the subintervals [<tt><i>b<sub>k</sub></i></tt>, <tt><i>b<sub>k+1</sub></i></tt>) are commonly
- known as the <i>bins</i> of a histogram.
- </p>
-</blockquote>
-</blockquote>
-</li>
-</ol>
-
-
-
-
-
-
-<hr>
-<h3><a name="800"></a>800. Issues in 26.4.7.1 [rand.util.seedseq](6)</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2008-02-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The for-loop in the algorithm specification has <tt>n</tt> iterations, where <tt>n</tt> is
-defined to be <tt>end - begin</tt>, i.e. the number of supplied w-bit quantities.
-Previous versions of this algorithm and the general logic behind it
-suggest that this is an oversight and that in the context of the
-for-loop <tt>n</tt> should be the number of full 32-bit quantities in <tt>b</tt> (rounded
-upwards). If <tt>w</tt> is 64, the current algorithm throws away half of all bits
-in <tt>b</tt>. If <tt>w</tt> is 16, the current algorithm sets half of all elements in <tt>v</tt>
-to 0.
-</p>
-
-<p>
-There are two more minor issues:
-</p>
-
-<ul>
-<li>
-Strictly speaking <tt>end - begin</tt> is not defined since
-<tt>InputIterator</tt> is not required to be a random access iterator.
-</li>
-<li>
-Currently all integral types are allowed as input to the <tt>seed_seq</tt>
-constructor, including <tt>bool</tt>. IMHO allowing <tt>bool</tt>s unnecessarily
-complicates the implementation without any real benefit to the user.
-I'd suggest to exclude <tt>bool</tt>s as input.
-</li>
-</ul>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Move to OPEN Bill will try to propose a resolution by the next meeting.
-</blockquote>
-
-<p><i>[
-post Bellevue: Bill provided wording.
-]</i></p>
-
-
-<p>
-This issue is made moot if <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> is accepted.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Replace 26.4.7.1 [rand.util.seedseq] paragraph 6 with:
-</p>
-
-<blockquote>
-<p>
-<i>Effects:</i> Constructs a <tt>seed_seq</tt> object by effectively concatenating the
-low-order <tt>u</tt> bits of each of the elements of the supplied sequence <tt>[begin,
-end)</tt>
-in ascending order of significance to make a (possibly very large) unsigned
-binary number <tt>b</tt> having a total of <tt>n</tt> bits, and then carrying out the
-following
-algorithm:
-</p>
-
-<blockquote><pre>for( v.clear(); n &gt; 0; n -= 32 )
- v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
-</pre></blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="801"></a>801. <tt>tuple</tt> and <tt>pair</tt> trivial members</h3>
-<p><b>Section:</b> 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-02-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#tuple">active issues</a> in [tuple].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#tuple">issues</a> in [tuple].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Classes with trivial special member functions are inherently more
-efficient than classes without such functions. This efficiency is
-particularly pronounced on modern ABIs that can pass small classes
-in registers. Examples include value classes such as complex numbers
-and floating-point intervals. Perhaps more important, though, are
-classes that are simple collections, like <tt>pair</tt> and <tt>tuple</tt>. When the
-parameter types of these classes are trivial, the <tt>pair</tt>s and <tt>tuple</tt>s
-themselves can be trivial, leading to substantial performance wins.
-</p>
-<p>
-The current working draft make specification of trivial functions
-(where possible) much easer through <tt>default</tt>ed and <tt>delete</tt>d functions.
-As long as the semantics of defaulted and deleted functions match
-the intended semantics, specification of defaulted and deleted
-functions will yield more efficient programs.
-</p>
-<p>
-There are at least two cases where specification of an explicitly
-defaulted function may be desirable.
-</p>
-<p>
-First, the <tt>std::pair</tt> template has a non-trivial default constructor,
-which prevents static initialization of the pair even when the
-types are statically initializable. Changing the definition to
-</p>
-
-<blockquote><pre>pair() = default;
-</pre></blockquote>
-
-<p>
-would enable such initialization. Unfortunately, the change is
-not semantically neutral in that the current definition effectively
-forces value initialization whereas the change would not value
-initialize in some contexts.
-</p>
-
-<p>
-** Does the committee confirm that forced value initialization
-was the intent? If not, does the committee wish to change the
-behavior of <tt>std::pair</tt> in C++0x?
-</p>
-<p>
-Second, the same default constructor issue applies to <tt>std::tuple</tt>.
-Furthermore, the <tt>tuple</tt> copy constructor is current non-trivial,
-which effectively prevents passing it in registers. To enable
-passing <tt>tuples</tt> in registers, the copy constructor should be
-make explicitly <tt>default</tt>ed. The new declarations are:
-</p>
-
-<blockquote><pre>tuple() = default;
-tuple(const tuple&amp;) = default;
-</pre></blockquote>
-
-<p>
-This changes is not implementation neutral. In particular, it
-prevents implementations based on pointers to the parameter
-types. It does however, permit implementations using the
-parameter types as bases.
-</p>
-<p>
-** How does the committee wish to trade implementation
-efficiency versus implementation flexibility?
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-General agreement; the first half of the issue is NAD.
-</p>
-<p>
-Before voting on the second half, it was agreed that a "Strongly Favor"
-vote meant support for trivial tuples (assuming usual requirements met),
-even at the expense of other desired qualities. A "Weakly Favor" vote
-meant support only if not at the expense of other desired qualities.
-</p>
-<p>
-Concensus: Go forward, but not at expense of other desired qualities.
-</p>
-<p>
-It was agreed to Alisdair should fold this work in with his other
-pair/tuple action items, above, and that issue 801 should be "open", but
-tabled until Alisdair's proposals are disposed of.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="803"></a>803. Simplification of <tt>seed_seq::seq_seq</tt></h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2008-02-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>seed_seq(InputIterator begin, InputIterator end);</tt> constructs a <tt>seed_seq</tt>
-object repacking the bits of supplied sequence <tt>[begin, end)</tt> into a
-32-bit vector.
-</p>
-<p>
-This repacking triggers several problems:
-</p>
-<ol>
-<li>
-Distinctness of the output of <tt>seed_seq::generate</tt> required the
-introduction of the initial "<tt>if (w &lt; 32) v.push_back(n);</tt>" (Otherwise
-the unsigned short vectors [1, 0] and [1] generate the same sequence.)
-</li>
-<li>
-Portability demanded the introduction of the template parameter <tt>u</tt>.
-(Otherwise some sequences could not be obtained on computers where no
-integer types are exactly 32-bits wide.)
-</li>
-<li>
-The description and algorithm have become unduly complicated.
-</li>
-</ol>
-<p>
-I propose simplifying this <tt>seed_seq</tt> constructor to be "32-bit only".
-Despite it's being simpler, there is NO loss of functionality (see
-below).
-</p>
-<p>
-Here's how the description would read
-</p>
-<blockquote>
-<p>
-26.4.7.1 [rand.util.seedseq] Class <tt>seed_seq</tt>
-</p>
-
-<blockquote>
-<pre>template&lt;class InputIterator&gt;
- seed_seq(InputIterator begin, InputIterator end);
-</pre>
-<blockquote>
-<p>
-5 <i>Requires:</i> NO CHANGE
-</p>
-<p>
-6 <i>Effects:</i> Constructs a <tt>seed_seq</tt> object by
-</p>
-<blockquote>
-<pre>for (InputIterator s = begin; s != end; ++s)
- v.push_back((*s) mod 2^32);
-</pre>
-</blockquote>
-</blockquote>
-</blockquote>
-</blockquote>
-
-<p>
-Discussion:
-</p>
-<p>
-The chief virtues here are simplicity, portability, and generality.
-</p>
-<ul>
-<li>
-Simplicity -- compare the above specification with the
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a> proposal.
-</li>
-<li>
-Portability -- with <tt>iterator_traits&lt;InputIterator&gt;::value_type =
-uint_least32_t</tt> the user is guaranteed to get the same behavior across
-platforms.
-</li>
-<li>
-Generality -- any behavior that the
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
-proposal can achieve can be
-obtained with this simpler proposal (albeit with a shuffling of bits
-in the input sequence).
-</li>
-</ul>
-<p>
-Arguments (and counter-arguments) against making this change (and
-retaining the
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
-behavior) are:
-</p>
-<ul>
-<li>
-<p>
-The user can pass an array of <tt>unsigned char</tt> and <tt>seed_seq</tt> will nicely
- repack it.
-</p>
-<p>
- Response: So what? Consider the seed string "ABC". The
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
- proposal results in
-</p>
-<blockquote><pre>v = { 0x3, 0x434241 };
-</pre></blockquote>
-<p>
-while the simplified proposal yields
-</p>
-<blockquote><pre>v = { 0x41, 0x42, 0x43 };
-</pre></blockquote>
-<p>
-The results produced by <tt>seed_seq::generate</tt> with the two inputs are
-different but nevertheless equivalently "mixed up" and this remains
-true even if the seed string is long.
-</p>
-</li>
-<li>
-<p>
-With long strings (e.g., with bit-length comparable to the number of
- bits in the state), <tt>v</tt> is longer (by a factor of 4) with the simplified
- proposal and <tt>seed_seq::generate</tt> will be slower.
-</p>
-<p>
-Response: It's unlikely that the efficiency of <tt>seed_seq::generate</tt> will
- be a big issue. If it is, the user is free to repack the seed vector
- before constructing <tt>seed_seq</tt>.
-</p>
-</li>
-<li>
-<p>
-A user can pass an array of 64-bit integers and all the bits will be
- used.
-</p>
-<p>
- Response: Indeed. However, there are many instances in the
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
- where integers are silently coerced to a narrower width and this
- should just be a case of the user needing to read the documentation.
- The user can of course get equivalent behavior by repacking his seed
- into 32-bit pieces. Furthermore, the unportability of the
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">n2461</a>
- proposal with
-</p>
-<blockquote><pre>unsigned long s[] = {1, 2, 3, 4};
-seed_seq q(s, s+4);
-</pre></blockquote>
-<p>
- which typically results in <tt>v = {1, 2, 3, 4}</tt> on 32-bit machines and in
-<tt>v = {1, 0, 2, 0, 3, 0, 4, 0}</tt> on 64-bit machines is a major pitfall for
- unsuspecting users.
-</p>
-</li>
-</ul>
-
-<p>
-Note: this proposal renders moot issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Walter needs to ask Fermilab for guidance. Defer till tomorrow. Bill likes the proposed resolution.
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-Marc Paterno wants portable behavior between 32bit and 64bit machines;
-we've gone to significant trouble to support portability of engines and
-their values.
-</p>
-<p>
-Jens: the new algorithm looks perfectly portable
-</p>
-<p>
-Marc Paterno to review off-line.
-</p>
-<p>
-Modify the proposed resolution to read "Constructs a seed_seq object by the following algorithm ..."
-</p>
-<p>
-Disposition: move to review; unanimous consent.
-</p>
-<p>
-(moots <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>)
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.4.7.1 [rand.util.seedseq]:
-</p>
-
-<blockquote>
-<pre>template&lt;class InputIterator<del>,
- size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
- seed_seq(InputIterator begin, InputIterator end);
-</pre>
-<blockquote>
-<p>
--5- <i>Requires:</i> <tt>InputIterator</tt> shall satisfy the requirements of an input iterator (24.1.1)
-such that <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt> shall denote an integral type.
-</p>
-<p>
--6- Constructs a <tt>seed_seq</tt> object by <ins>the following algorithm</ins> <del>rearranging some or all of the bits of the supplied sequence
-<tt>[begin,end)</tt> of w-bit quantities into 32-bit units, as if by the following: </del>
-</p>
-<p>
-<del>First extract the rightmost <tt>u</tt> bits from each of the <tt>n = end
-- begin</tt> elements of the supplied sequence and concatenate all the
-extracted bits to initialize a single (possibly very large) unsigned
-binary number, <tt>b = &#8721;<sup>n-1</sup><sub>i=0</sub> (begin[i]
-mod 2<sup>u</sup>) 2<sup>wi</sup></tt> (in which the bits of each <tt>begin[i]</tt>
-are treated as denoting an unsigned quantity). Then carry out
-the following algorithm:</del>
-</p>
-<blockquote><pre><del>
-v.clear();
-if ($w$ &lt; 32)
- v.push_back($n$);
-for( ; $n$ &gt; 0; --$n$)
- v.push_back(b mod 2<sup>32</sup>), b /= 2<sup>32</sup>;
-</del></pre></blockquote>
-<blockquote>
-<pre><ins>
-for (InputIterator s = begin; s != end; ++s)
- v.push_back((*s) mod 2<sup>32</sup>);
-</ins></pre>
-</blockquote>
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="804"></a>804. Some problems with classes <tt>error_code</tt>/<tt>error_condition</tt></h3>
-<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-02-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<ol type="A">
-<li>
-<p>
-19.4.2.1 [syserr.errcode.overview]/1, class <tt>error_code</tt> and
-19.4.3.1 [syserr.errcondition.overview]/, class <tt>error_condition</tt> synopses
-declare an expository data member <tt>cat_</tt>:
-</p>
-<blockquote><pre>const error_category&amp; cat_; // exposition only
-</pre></blockquote>
-<p>
-which is used to define the semantics of several members. The decision
-to use a member of reference type lead to several problems:
-</p>
-<ol>
-<li>
-The classes are not <tt>(Copy)Assignable</tt>, which is probably not the intent.
-</li>
-<li>
-The post conditions of all modifiers from
-19.4.2.3 [syserr.errcode.modifiers] and 19.4.3.3 [syserr.errcondition.modifiers], resp.,
-cannot be fulfilled.
-</li>
-</ol>
-<p>
-The simple fix would be to replace the reference by a pointer member.
-</p>
-</li>
-
-<li>
-I would like to give the editorial remark that in both classes the
-constrained <tt>operator=</tt>
-overload (template with <tt>ErrorCodeEnum</tt> argument) makes in invalid
-usage of <tt>std::enable_if</tt>: By using the default value for the second <tt>enable_if</tt>
-parameter the return type would be defined to be <tt>void&amp;</tt> even in otherwise
-valid circumstances - this return type must be explicitly provided (In
-<tt>error_condition</tt> the first declaration uses an explicit value, but of wrong
-type).
-</li>
-
-<li>
-The member function <tt>message</tt> throws clauses (
-19.4.1.2 [syserr.errcat.virtuals]/10, 19.4.2.4 [syserr.errcode.observers]/8, and
-19.4.3.4 [syserr.errcondition.observers]/6) guarantee "throws nothing",
-although
-they return a <tt>std::string</tt> by value, which might throw in out-of-memory
-conditions (see related issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>).
-</li>
-</ol>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-Part A: NAD (editorial), cleared by the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.
-</p>
-<p>
-Part B: Technically correct, save for typo. Rendered moot by the concept proposal
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2620.html">N2620</a>) NAD (editorial).
-</p>
-<p>
-Part C: We agree; this is consistent with the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>.
-</p>
-<p>
-Howard: please ping Beman, asking him to clear away parts A and B from
-the wording in the proposed resolution, so it is clear to the editor
-what needs to be applied to the working paper.
-</p>
-<p>
-Beman provided updated wording. Since issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a> is not going
-forward, the provided wording includes resolution of part A.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Resolution of part A:
-</p>
-<blockquote>
-<p>
-Change 19.4.2.1 [syserr.errcode.overview] Class error_code overview synopsis as indicated:
-</p>
-
-<blockquote><pre>private:
- int val_; // exposition only
- const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
-</pre></blockquote>
-
-<p>
-Change 19.4.2.2 [syserr.errcode.constructors] Class error_code constructors as indicated:
-</p>
-
-<blockquote>
-<pre>error_code();
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>system_category</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-<pre>error_code(int val, const error_category&amp; cat);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-Change 19.4.2.3 [syserr.errcode.modifiers] Class error_code modifiers as indicated:
-</p>
-
-<blockquote>
-<pre>void assign(int val, const error_category&amp; cat);
-</pre>
-<blockquote>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-Change 19.4.2.4 [syserr.errcode.observers] Class error_code observers as indicated:
-</p>
-
-<blockquote>
-const error_category&amp; category() const;
-<blockquote>
-<p>
-<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-Change 19.4.3.1 [syserr.errcondition.overview] Class error_condition overview synopsis as indicated:
-</p>
-
-<blockquote><pre>private:
- int val_; // exposition only
- const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
-</pre></blockquote>
-
-<p>
-Change 19.4.3.2 [syserr.errcondition.constructors] Class error_condition constructors as indicated:
-</p>
-<p><i>[
-(If the proposed resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has already been applied, the
-name <tt>posix_category</tt> will have been changed to <tt>generic_category</tt>. That has
-no effect on this resolution.)
-]</i></p>
-
-
-<blockquote>
-<pre>error_condition();
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>val_ == 0</tt> and <tt>cat_ == <ins>&amp;</ins>posix_category</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-<pre>error_condition(int val, const error_category&amp; cat);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-Change 19.4.3.3 [syserr.errcondition.modifiers] Class error_condition modifiers as indicated:
-</p>
-
-<blockquote>
-void assign(int val, const error_category&amp; cat);
-<blockquote>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == <ins>&amp;</ins>cat</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-Change 19.4.3.4 [syserr.errcondition.observers] Class error_condition observers as indicated:
-</p>
-
-<blockquote>
-const error_category&amp; category() const;
-<blockquote>
-<p>
-<i>Returns:</i> <tt><ins>*</ins>cat_</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-</blockquote>
-</blockquote>
-
-<p>
-Resolution of part C:
-</p>
-
-<blockquote>
-
-<p>
-In 19.4.1.2 [syserr.errcat.virtuals], remove the throws clause p. 10.
-</p>
-
-<blockquote>
-<pre>virtual string message(int ev) const = 0;
-</pre>
-
-<blockquote>
-<p>
-<i>Returns:</i> A string that describes the error condition denoted by <tt>ev</tt>.
-</p>
-<p>
-<del><i>Throws:</i> Nothing.</del>
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-In 19.4.2.4 [syserr.errcode.observers], remove the throws clause p. 8.
-</p>
-
-<blockquote>
-<pre>string message() const;
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>category().message(value())</tt>.
-</p>
-<p>
-<del><i>Throws:</i> Nothing.</del>
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-In 19.4.3.4 [syserr.errcondition.observers], remove the throws clause p. 6.
-</p>
-
-<blockquote>
-<pre>string message() const;
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>category().message(value())</tt>.
-</p>
-<p>
-<del><i>Throws:</i> Nothing.</del>
-</p>
-</blockquote>
-</blockquote>
-
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="805"></a>805. <tt>posix_error::posix_errno</tt> concerns</h3>
-<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-02-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-19.4 [syserr]
-</p>
-
-<blockquote><pre>namespace posix_error {
- enum posix_errno {
- address_family_not_supported, // EAFNOSUPPORT
- ...
-</pre></blockquote>
-
-<p>
-should rather use the new scoped-enum facility (7.2 [dcl.enum]),
-which would avoid the necessity for a new <tt>posix_error</tt>
-namespace, if I understand correctly.
-</p>
-
-<p><i>[
-Further discussion:
-]</i></p>
-
-
-<blockquote>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf">N2347</a>,
-Strongly Typed Enums, since renamed Scoped Enums.
-</p>
-<p>
-Alberto Ganesh Barbati also raised this issue in private email, and also proposed the scoped-enum solution.
-</p>
-<p>
-Nick Stoughton asked in Bellevue that <tt>posix_error</tt> and <tt>posix_errno</tt> not be used as names. The LWG agreed.
-</p>
-<p>
-The wording for the Proposed resolution was provided by Beman Dawes.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change System error support 19.4 [syserr] as indicated:
-</p>
-
-<blockquote><pre><del>namespace posix_error {</del>
- enum <del>posix_errno</del> <ins>class errc</ins> {
- address_family_not_supported, // EAFNOSUPPORT
- ...
- wrong_protocol_type, // EPROTOTYPE
- };
-<del>} // namespace posix_error</del>
-
-template &lt;&gt; struct is_error_condition_enum&lt;<del>posix_error::posix_errno</del> <ins>errc</ins>&gt;
- : public true_type {}
-
-<del>namespace posix_error {</del>
- error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
- error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
-<del>} // namespace posix_error</del>
-</pre></blockquote>
-
-<p>
-Change System error support 19.4 [syserr] :
-</p>
-
-<blockquote>
-<del>The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> templates may be
-specialized for user-defined types to indicate that such a type is
-eligible for class <tt>error_code</tt> and class <tt>error_condition</tt> automatic
-conversions, respectively.</del>
-</blockquote>
-
-<p>
-Change System error support 19.4 [syserr] and its subsections:
-</p>
-
-<blockquote>
-<ul>
-<li>
-remove all occurrences of <tt>posix_error::</tt>
-</li>
-<li>
-change all instances of <tt>posix_errno</tt> to <tt>errc</tt>
-</li>
-<li>
-change all instances of <tt>posix_category</tt> to <tt>generic_category</tt>
-</li>
-<li>
-change all instances of <tt>get_posix_category</tt> to <tt>get_generic_category</tt>
-</li>
-</ul>
-</blockquote>
-
-<p>
-Change Error category objects 19.4.1.5 [syserr.errcat.objects], paragraph 2:
-</p>
-
-<blockquote>
-<i>Remarks:</i> The object's <tt>default_error_condition</tt> and equivalent virtual
-functions shall behave as specified for the class <tt>error_category</tt>. The
-object's name virtual function shall return a pointer to the string
-<del>"POSIX"</del> <ins>"GENERIC"</ins>.
-</blockquote>
-
-<p>
-Change 19.4.2.5 [syserr.errcode.nonmembers] Class <tt>error_code</tt> non-member functions as indicated:
-</p>
-
-<blockquote>
-<pre>error_code make_error_code(<del>posix_errno</del> <ins>errc</ins> e);
-</pre>
-
-<blockquote>
-<i>Returns:</i> <tt>error_code(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
-</blockquote>
-</blockquote>
-
-<p>
-Change 19.4.3.5 [syserr.errcondition.nonmembers] Class <tt>error_condition</tt> non-member functions as indicated:
-</p>
-
-<blockquote>
-<pre>error_condition make_error_condition(<del>posix_errno</del> <ins>errc</ins> e);
-</pre>
-
-<blockquote>
-<i>Returns:</i> <tt>error_condition(<ins>static_cast&lt;int&gt;(</ins>e<ins>)</ins>, <del>posix</del><ins>generic</ins>_category)</tt>.
-</blockquote>
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<table border="1">
-<tbody><tr>
-<th colspan="2">Names Considered</th>
-</tr>
-
-<tr>
-<td><tt>portable</tt></td>
-<td>
-Too non-specific. Did not wish to reserve such a common word in
-namespace std. Not quite the right meaning, either.
-</td>
-</tr>
-
-<tr>
-<td><tt>portable_error</tt></td>
-<td>
-Too long. Explicit qualification is always required for scoped enums, so
-a short name is desirable. Not quite the right meaning, either. May be
-misleading because <tt>*_error</tt> in the std lib is usually an exception class
-name.
-</td>
-</tr>
-
-<tr>
-<td><tt>std_error</tt></td>
-<td>
-Fairly short, yet explicit. But in fully qualified names like
-<tt>std::std_error::not_enough_memory</tt>, the std_ would be unfortunate. Not
-quite the right meaning, either. May be misleading because <tt>*_error</tt> in
-the std lib is usually an exception class name.
-</td>
-</tr>
-
-<tr>
-<td><tt>generic</tt></td>
-<td>
-Short enough. The category could be <tt>generic_category</tt>. Fully qualified
-names like <tt>std::generic::not_enough_memory</tt> read well. Reserving in
-namespace std seems dicey.
-</td>
-</tr>
-
-<tr>
-<td><tt>generic_error</tt></td>
-<td>
-Longish. The category could be <tt>generic_category</tt>. Fully qualified names
-like <tt>std::generic_error::not_enough_memory</tt> read well. Misleading because
-<tt>*_error</tt> in the std lib is usually an exception class name.
-</td>
-</tr>
-
-<tr>
-<td><tt>generic_err</tt></td>
-<td>
-A bit less longish. The category could be <tt>generic_category</tt>. Fully
-qualified names like <tt>std::generic_err::not_enough_memory</tt> read well.
-</td>
-</tr>
-
-<tr>
-<td><tt>gen_err</tt></td>
-<td>
-Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
-names like <tt>std::gen_err::not_enough_memory</tt> read well.
-</td>
-</tr>
-
-<tr>
-<td><tt>generr</tt></td>
-<td>
-Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
-names like <tt>std::generr::not_enough_memory</tt> read well.
-</td>
-</tr>
-
-<tr>
-<td><tt>error</tt></td>
-<td>
-Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
-names like <tt>std::error::not_enough_memory</tt> read well. Do we want to use
-this general a name?
-</td>
-</tr>
-
-<tr>
-<td><tt>err</tt></td>
-<td>
-Shorter still. The category could be <tt>generic_category</tt>. Fully qualified
-names like <tt>std::err::not_enough_memory</tt> read well. Although alone it
-looks odd as a name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names,
-it seems fairly intuitive.
-Problem: <tt>err</tt> is used throughout the standard library as an argument name
-and in examples as a variable name; it seems too confusing to add yet
-another use of the name.
-</td>
-</tr>
-
-<tr>
-<td><tt>errc</tt></td>
-<td>
-Short enough. The "c" stands for "constant". The category could be
-<tt>generic_category</tt>. Fully qualified names like
-<tt>std::errc::not_enough_memory</tt> read well. Although alone it looks odd as a
-name, given the existing <tt>errno</tt> and <tt>namespace std</tt> names, it seems fairly
-intuitive. There are no uses of <tt>errc</tt> in the current C++ standard.
-</td>
-</tr>
-</tbody></table>
-
-
-
-
-
-<hr>
-<h3><a name="806"></a>806. <tt>unique_ptr::reset</tt> effects incorrect, too permissive</h3>
-<p><b>Section:</b> 20.7.11.2.5 [unique.ptr.single.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-03-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>void unique_ptr::reset(T* p = 0)</tt> is currently specified as:
-</p>
-
-<blockquote>
-<i>Effects:</i> If <tt>p == get()</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
-</blockquote>
-
-<p>
-There are two problems with this. One, if <tt>get() == 0</tt> and <tt>p != 0</tt>, the
-deleter is called with a NULL pointer, and this is probably not what's
-intended (the destructor avoids calling the deleter with 0.)
-</p>
-
-<p>
-Two, the special check for <tt>get() == p</tt> is generally not needed and such a
-situation usually indicates an error in the client code, which is being
-masked. As a data point, <tt>boost::shared_ptr</tt> was changed to assert on such
-self-resets in 2001 and there were no complaints.
-</p>
-
-<p>
-One might think that self-resets are necessary for operator= to work; it's specified to perform
-</p>
-
-<blockquote><pre>reset( u.release() );
-</pre></blockquote>
-
-<p>
-and the self-assignment
-</p>
-
-<blockquote><pre>p = move(p);
-</pre></blockquote>
-
-<p>
-might appear to result in a self-reset. But it doesn't; the <tt>release()</tt> is
-performed first, zeroing the stored pointer. In other words, <tt>p.reset(
-q.release() )</tt> works even when <tt>p</tt> and <tt>q</tt> are the same <tt>unique_ptr</tt>, and there
-is no need to special-case <tt>p.reset( q.get() )</tt> to work in a similar
-scenario, as it definitely doesn't when <tt>p</tt> and <tt>q</tt> are separate.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 20.7.11.2.5 [unique.ptr.single.modifiers]:
-</p>
-
-<blockquote>
-<pre>void reset(T* p = 0);
-</pre>
-<blockquote>
--4- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
-</blockquote>
-</blockquote>
-
-<p>
-Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:
-</p>
-
-<blockquote>
-<pre>void reset(T* p = 0);
-</pre>
-<blockquote>
-<p>...</p>
-<p>
--2- <i>Effects:</i> If <tt><del>p ==</del> get()<ins> == 0</ins></tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="807"></a>807. <tt>tuple</tt> construction should not fail unless its element's construction fails</h3>
-<p><b>Section:</b> 20.4.1.2 [tuple.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> Added a throws clause to <tt>bind</tt> constructors. I believe the same throws clause
-should be added to <tt>tuple</tt> except it ought to take into account move constructors as well.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to 20.4.1.2 [tuple.cnstr]:
-</p>
-
-<blockquote>
-<p>
-For each <tt>tuple</tt> constructor and assignment operator, an exception is thrown only if the construction
-or assignment of one of the types in <tt>Types</tt> throws an exception.
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="808"></a>808. [forward] incorrect redundant specification</h3>
-<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-p4 (forward) says:
-</p>
-<blockquote>
-<i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.
-</blockquote>
-
-<p>
-First of all, lvalue-ness and rvalue-ness are properties of an expression,
-not of a type (see 3.10 [basic.lval]). Thus, the phrasing "Return type" is wrong.
-Second, the phrase says exactly what the core language wording says for
-folding references in 14.3.1 [temp.arg.type]/p4 and for function return values
-in 5.2.2 [expr.call]/p10. (If we feel the wording should be retained, it should
-at most be a note with cross-references to those sections.)
-</p>
-<p>
-The prose after the example talks about "forwarding as an <tt>int&amp;</tt> (an lvalue)" etc.
-In my opinion, this is a category error: "<tt>int&amp;</tt>" is a type, "lvalue" is a
-property of an expression, orthogonal to its type. (Btw, expressions cannot
-have reference type, ever.)
-</p>
-<p>
-Similar with move:
-</p>
-<blockquote>
-Return type: an rvalue.
-</blockquote>
-<p>
-is just wrong and also redundant.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.2.2 [forward] as indicated:
-</p>
-
-<blockquote>
-<pre>template &lt;class T&gt; T&amp;&amp; forward(typename identity&lt;T&gt;::type&amp;&amp; t);
-</pre>
-
-<blockquote>
-<p>...</p>
-<p>
-<del><i>Return type:</i> If <tt>T</tt> is an lvalue-reference type, an lvalue; otherwise, an rvalue.</del>
-</p>
-<p>...</p>
-<p>
--7- In the first call to <tt>factory</tt>, <tt>A1</tt> is deduced as <tt>int</tt>, so 2 is forwarded to <tt>A</tt>'s constructor
-as <del>an <tt>int&amp;&amp;</tt> (</del>an rvalue<del>)</del>. In the second call to factory, <tt>A1</tt> is deduced
-as <tt>int&amp;</tt>, so <tt>i</tt> is forwarded to <tt>A</tt>'s constructor as <del>an <tt>int&amp;</tt> (</del>an lvalue<del>)</del>.
-In both cases, <tt>A2</tt> is deduced as double, so 1.414 is forwarded to <tt>A</tt>'s constructor as
-<del><tt>double&amp;&amp;</tt> (</del>an rvalue<del>)</del>.
-</p>
-</blockquote>
-
-<pre>template &lt;class T&gt; typename remove_reference&lt;T&gt;::type&amp;&amp; move(T&amp;&amp; t);
-</pre>
-
-<blockquote>
-<p>...</p>
-<p>
-<del><i>Return type:</i> an rvalue.</del>
-</p>
-</blockquote>
-
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="809"></a>809. std::swap should be overloaded for array types</h3>
-<p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-02-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-For the sake of generic programming, the header <code>&lt;algorithm&gt;</code> should provide an
-overload of <code>std::swap</code> for array types:
-</p><pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
-</pre>
-
-
-<p>
-It became apparent to me that this overload is missing, when I considered how to write a swap
-function for a generic wrapper class template.
-(Actually I was thinking of Boost's <a href="http://www.boost.org/libs/utility/value_init.htm">value_initialized</a>.)
-Please look at the following template, <code>W</code>, and suppose that is intended to be a very
-<em>generic</em> wrapper:
-</p><pre>template&lt;class T&gt; class W {
-public:
- T data;
-};
-</pre>
-Clearly <code>W&lt;T&gt;</code> is <em>CopyConstructible and CopyAssignable</em>, and therefore
-<em>Swappable</em>, whenever <code>T</code> is <em>CopyConstructible and CopyAssignable</em>.
-Moreover, <code>W&lt;T&gt;</code> is <em>also</em> Swappable when <code>T</code> is an array type
-whose element type is CopyConstructible and CopyAssignable.
-Still it is recommended to add a <em>custom</em> swap function template to such a class template,
-for the sake of efficiency and exception safety.
-(E.g., <em>Scott Meyers, Effective C++, Third Edition, item 25: Consider support for a non-throwing
-swap</em>.)
-This function template is typically written as follows:
-<pre>template&lt;class T&gt; void swap(W&lt;T&gt;&amp; x, W&lt;T&gt;&amp; y) {
- using std::swap;
- swap(x.data, y.data);
-}
-</pre>
-Unfortunately, this will introduce an undesirable inconsistency, when <code>T</code> is an array.
-For instance, <code>W&lt;std::string[8]&gt;</code> is Swappable, but the current Standard does not
-allow calling the custom swap function that was especially written for <code>W</code>!
-<pre>W&lt;std::string[8]&gt; w1, w2; // Two objects of a Swappable type.
-std::swap(w1, w2); // Well-defined, but inefficient.
-using std::swap;
-swap(w1, w2); // Ill-formed, just because ADL finds W's swap function!!!
-</pre>
-
-<code>W</code>'s <code>swap</code> function would try to call <code>std::swap</code> for an array,
-<code>std::string[8]</code>, which is not supported by the Standard Library.
-This issue is easily solved by providing an overload of <code>std::swap</code> for array types.
-This swap function should be implemented in terms of swapping the elements of the arrays, so that
-it would be non-throwing for arrays whose element types have a non-throwing swap.
-
-
-<p>
-Note that such an overload of <code>std::swap</code> should also support <em>multi-dimensional</em>
-arrays. Fortunately that isn't really an issue, because it would do so <i>automatically</i>, by
-means of recursion.
-</p>
-
-<p>
-For your information, there was a discussion on this issue at comp.lang.c++.moderated: <a href="http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/9341ebd3635c9c74">[Standard
-Library] Shouldn't std::swap be overloaded for C-style arrays?</a>
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add an extra condition to the definition of Swappable requirements [swappable] in 20.1.1 [utility.arg.requirements]:
-</p>
-<blockquote>
-- <tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> is an array type whose element type is <tt>Swappable</tt>.
-</blockquote>
-<p>
-Add the following to 25.2.3 [alg.swap]:
-</p>
-<blockquote>
-<pre>template&lt;class T, size_t N&gt; void swap(T (&amp;a)[N], T (&amp;b)[N]);
-</pre>
-<blockquote>
-<i>Requires:</i> Type <code>T</code> shall be <tt>Swappable</tt>.
-</blockquote>
-<blockquote>
-<i>Effects:</i> <code>swap_ranges(a, a + N, b);</code>
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="810"></a>810. Missing traits dependencies in operational semantics of extended manipulators</h3>
-<p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-03-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The recent draft (as well as the original proposal n2072) uses an
-operational semantic
-for <tt>get_money</tt> ([ext.manip]/3) and <tt>put_money</tt> ([ext.manip]/5), which uses
-</p>
-
-<blockquote><pre>istreambuf_iterator&lt;charT&gt;
-</pre></blockquote>
-
-<p>
-and
-</p>
-
-<blockquote><pre>ostreambuf_iterator&lt;charT&gt;
-</pre></blockquote>
-
-<p>
-resp, instead of the iterator instances, with explicitly provided
-traits argument (The operational semantic defined by <tt>f</tt> is also traits
-dependent). This is an obvious oversight because both <tt>*stream_buf</tt>
-c'tors expect a <tt>basic_streambuf&lt;charT,traits&gt;</tt> as argument.
-</p>
-<p>
-The same problem occurs within the <tt>get_time</tt> and <tt>put_time</tt> semantic (p.
-7 and p. 9)
-of n2071 incorporated in N2521, where additional to the problem we
-have an editorial issue in <tt>get_time</tt> (<tt>streambuf_iterator</tt> instead of
-<tt>istreambuf_iterator</tt>).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.6.4 [ext.manip]/3 within function <tt>f</tt> replace the first line
-</p>
-
-<blockquote><pre>template &lt;class charT, class traits, class moneyT&gt;
-void f(basic_ios&lt;charT, traits&gt;&amp; str, moneyT&amp; mon, bool intl) {
- typedef istreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
- ...
-</pre></blockquote>
-
-<p>
-In 27.6.4 [ext.manip]/4 remove the first template <tt>charT</tt> parameter:
-</p>
-
-<blockquote><pre>template &lt;<del>class charT, </del>class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false<ins>)</ins>;
-</pre></blockquote>
-
-<p>
-In 27.6.4 [ext.manip]/5 within function <tt>f</tt> replace the first line
-</p>
-
-<blockquote><pre>template &lt;class charT, class traits, class moneyT&gt;
-void f(basic_ios&lt;charT, traits&gt;&amp; str, const moneyT&amp; mon, bool intl) {
- typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
- ...
-</pre></blockquote>
-
-<p>
-In 27.6.4 [ext.manip]/7 within function <tt>f</tt> replace the first line
-</p>
-
-<blockquote><pre>template &lt;class charT, class traits&gt;
-void f(basic_ios&lt;charT, traits&gt;&amp; str, struct tm *tmb, const charT *fmt) {
- typedef <ins>i</ins>streambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
- ...
-</pre></blockquote>
-
-<p>
-In 27.6.4 [ext.manip]/8 add const:
-</p>
-
-<blockquote><pre>template &lt;class charT&gt; unspecified put_time(<ins>const</ins> struct tm *tmb, const charT *fmt);
-</pre></blockquote>
-
-<p>
-In 27.6.4 [ext.manip]/9 within function <tt>f</tt> replace the first line
-</p>
-
-<blockquote><pre>template &lt;class charT, class traits&gt;
-void f(basic_ios&lt;charT, traits&gt;&amp; str, const struct tm *tmb, const charT *fmt) {
- typedef ostreambuf_iterator&lt;charT<ins>, traits</ins>&gt; Iter;
- ...
-</pre></blockquote>
-
-<p>
-Add to the <tt>&lt;iomanip&gt;</tt> synopsis in 27.6 [iostream.format]
-</p>
-
-<blockquote><pre>template &lt;class moneyT&gt; unspecified get_money(moneyT&amp; mon, bool intl = false);
-template &lt;class moneyT&gt; unspecified put_money(const moneyT&amp; mon, bool intl = false);
-template &lt;class charT&gt; unspecified get_time(struct tm *tmb, const charT *fmt);
-template &lt;class charT&gt; unspecified put_time(const struct tm *tmb, const charT *fmt);
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="811"></a>811. <tt>pair</tt> of pointers no longer works with literal 0</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-03-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<blockquote><pre>#include &lt;utility&gt;
-
-int main()
-{
- std::pair&lt;char *, char *&gt; p (0,0);
-}
-</pre></blockquote>
-
-<p>
-I just got a bug report about that, because it's valid C++03, but not
-C++0x. The important realization, for me, is that the emplace
-proposal---which made <tt>push_back</tt> variadic, causing the <tt>push_back(0)</tt>
-issue---didn't cause this break in backward compatibility. The break
-actually happened when we added this pair constructor as part of adding
-rvalue references into the language, long before variadic templates or
-emplace came along:
-</p>
-
-<blockquote><pre>template&lt;class U, class V&gt; pair(U&amp;&amp; x, V&amp;&amp; y);
-</pre></blockquote>
-
-<p>
-Now, concepts will address this issue by constraining that <tt>pair</tt>
-constructor to only <tt>U</tt>'s and <tt>V</tt>'s that can properly construct "first" and
-"second", e.g. (from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2322.pdf">N2322</a>):
-</p>
-
-<blockquote><pre>template&lt;class U , class V &gt;
-requires Constructible&lt;T1, U&amp;&amp;&gt; &amp;&amp; Constructible&lt;T2, V&amp;&amp;&gt;
-pair(U&amp;&amp; x , V&amp;&amp; y );
-</pre></blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="812"></a>812. unsolicited multithreading considered harmful?</h3>
-<p><b>Section:</b> 25.3.1 [alg.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Paul McKenney <b>Date:</b> 2008-02-27</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Multi-threading is a good thing, but unsolicited multi-threading can
-potentially be harmful. For example, <tt>sort()</tt> performance might be
-greatly increased via a multithreaded implementation. However, such
-a multithreaded implementation could result in concurrent invocations
-of the user-supplied comparator. This would in turn result in problems
-given a caching comparator that might be written for complex sort keys.
-Please note that this is not a theoretical issue, as multithreaded
-implementations of <tt>sort()</tt> already exist.
-</p>
-<p>
-Having a multithreaded <tt>sort()</tt> available is good, but it should not
-be the default for programs that are not explicitly multithreaded.
-Users should not be forced to deal with concurrency unless they have
-asked for it.
-</p>
-
-<p><i>[
-This may be covered by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2410.html">N2410</a>
-Thread-Safety in the Standard Library (Rev 1).
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="813"></a>813. "empty" undefined for <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2008-02-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Several places in 20.7.12.2 [util.smartptr.shared] refer to an "empty" <tt>shared_ptr</tt>.
-However, that term is nowhere defined. The closest thing we have to a
-definition is that the default constructor creates an empty <tt>shared_ptr</tt>
-and that a copy of a default-constructed <tt>shared_ptr</tt> is empty. Are any
-other <tt>shared_ptr</tt>s empty? For example, is <tt>shared_ptr((T*) 0)</tt> empty? What
-are the properties of an empty <tt>shared_ptr</tt>? We should either clarify this
-term or stop using it.
-</p><p>
-</p>
-One reason it's not good enough to leave this term up to the reader's
-intuition is that, in light of
-<a href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2007/n2351.htm">N2351</a>
-and issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, most readers'
-intuitive understanding is likely to be wrong. Intuitively one might
-expect that an empty <tt>shared_ptr</tt> is one that doesn't store a pointer,
-but, whatever the definition is, that isn't it.
-
-
-<p><i>[
-Peter adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-Or, what is an "empty" <tt>shared_ptr</tt>?
-</p>
-
-<ul>
-<li>
-<p>
-Are any other <tt>shared_ptrs</tt> empty?
-</p>
-<p>
-Yes. Whether a given <tt>shared_ptr</tt> instance is empty or not is (*)
-completely specified by the last mutating operation on that instance.
-Give me an example and I'll tell you whether the <tt>shared_ptr</tt> is empty or
-not.
-</p>
-<blockquote>
-(*) If it isn't, this is a legitimate defect.
-</blockquote>
-</li>
-
-<li>
-<p>
-For example, is <tt>shared_ptr((T*) 0)</tt> empty?
-</p>
-<p>
-No. If it were empty, it would have a <tt>use_count()</tt> of 0, whereas it is
-specified to have an <tt>use_count()</tt> of 1.
-</p>
-</li>
-
-<li>
-<p>
-What are the properties of an empty <tt>shared_ptr</tt>?
-</p>
-<p>
-The properties of an empty <tt>shared_ptr</tt> can be derived from the
-specification. One example is that its destructor is a no-op. Another is
-that its <tt>use_count()</tt> returns 0. I can enumerate the full list if you
-really like.
-</p>
-</li>
-
-<li>
-<p>
-We should either clarify this term or stop using it.
-</p>
-<p>
-I don't agree with the imperative tone
-</p>
-<p>
-A clarification would be either a no-op - if it doesn't contradict the
-existing wording - or a big mistake if it does.
-</p>
-<p>
-I agree that a clarification that is formally a no-op may add value.
-</p>
-</li>
-
-<li>
-<p>
-However, that term is nowhere defined.
-</p>
-<p>
-Terms can be useful without a definition. Consider the following
-simplistic example. We have a type <tt>X</tt> with the following operations
-defined:
-</p>
-<blockquote><pre>X x;
-X x2(x);
-X f(X x);
-X g(X x1, X x2);
-</pre></blockquote>
-<p>
-A default-constructed value is green.<br>
-A copy has the same color as the original.<br>
-<tt>f(x)</tt> returns a red value if the argument is green, a green value otherwise.<br>
-<tt>g(x1,x2)</tt> returns a green value if the arguments are of the same color, a red value otherwise.
-</p>
-
-<p>
-Given these definitions, you can determine the color of every instance
-of type <tt>X</tt>, even if you have absolutely no idea what green and red mean.
-</p>
-
-<p>
-Green and red are "nowhere defined" and completely defined at the same time.
-</p>
-</li>
-</ul>
-
-<p>
-Alisdair's wording is fine.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Append the following sentance to 20.7.12.2 [util.smartptr.shared]
-</p>
-<blockquote>
-The <code>shared_ptr</code> class template stores a pointer, usually obtained
-via <code>new</code>. <code>shared_ptr</code> implements semantics of
-shared ownership; the last remaining owner of the pointer is responsible for
-destroying the object, or otherwise releasing the resources associated with
-the stored pointer. <ins>A <code>shared_ptr</code> object that does not own
-a pointer is said to be <i>empty</i>.</ins>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="814"></a>814. <tt>vector&lt;bool&gt;::swap(reference, reference)</tt> not defined</h3>
-<p><b>Section:</b> 23.2.7 [vector.bool] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#vector.bool">active issues</a> in [vector.bool].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.bool">issues</a> in [vector.bool].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>vector&lt;bool&gt;::swap(reference, reference)</tt> has no definition.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="815"></a>815. <tt>std::function</tt> and <tt>reference_closure</tt> do not use perfect forwarding</h3>
-<p><b>Section:</b> 20.6.15.2.4 [func.wrap.func.inv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-16</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>std::function</tt> and <tt>reference_closure</tt> should use "perfect forwarding" as
-described in the rvalue core proposal.
-</p>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-According to Doug Gregor, as far as <tt>std::function</tt> is concerned, perfect
-forwarding can not be obtained because of type erasure. Not everyone
-agreed with this diagnosis of forwarding.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="816"></a>816. Should <tt>bind()</tt>'s returned functor have a nofail copy ctor when <tt>bind()</tt> is nofail?</h3>
-<p><b>Section:</b> 20.6.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-02-08</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> notes that <tt>bind(f, t1, ..., tN)</tt>
-should be nofail when <tt>f, t1, ..., tN</tt> have nofail copy ctors.
-</p>
-<p>
-However, no guarantees are provided for the copy ctor of the functor
-returned by <tt>bind()</tt>. (It's guaranteed to have a copy ctor, which can
-throw implementation-defined exceptions: <tt>bind()</tt> returns a forwarding
-call wrapper, TR1 3.6.3/2. A forwarding call wrapper is a call wrapper,
-TR1 3.3/4. Every call wrapper shall be CopyConstructible, TR1 3.3/4.
-Everything without an exception-specification may throw
-implementation-defined exceptions unless otherwise specified, C++03
-17.4.4.8/3.)
-</p>
-<p>
-Should the nofail guarantee requested by Library Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a> be extended
-to cover both calling <tt>bind()</tt> and copying the returned functor?
-</p>
-
-<p><i>[
-Howard adds:
-]</i></p>
-
-
-<blockquote>
-<tt>tuple</tt> construction should probably have a similar guarantee.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="817"></a>817. <tt>bind</tt> needs to be moved</h3>
-<p><b>Section:</b> 20.6.11.1.3 [func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-03-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The functor retureed by <tt>bind()</tt> should have a move constructor that
-requires only move construction of its contained functor and bound arguments.
-That way move-only functors can be passed to objects such as <tt>thread</tt>.
-</p>
-<p>
-This issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="818"></a>818. wording for memory ordering</h3>
-<p><b>Section:</b> 29.1 [atomics.order] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-03-22</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-29.1 [atomics.order] p1 says in the table that
-</p>
-
-<blockquote>
-<table border="1">
-<tbody><tr>
-<th>Element</th><th>Meaning</th>
-</tr>
-<tr>
-<td><tt>memory_order_acq_rel</tt></td>
-<td>the operation has both acquire and release semantics</td>
-</tr>
-</tbody></table>
-</blockquote>
-
-<p>
-To my naked eye, that seems to imply that even an atomic read has both
-acquire and release semantics.
-</p>
-
-<p>
-Then, p1 says in the table:
-</p>
-
-<blockquote>
-<table border="1">
-<tbody><tr>
-<th>Element</th><th>Meaning</th>
-</tr>
-<tr>
-<td><tt>memory_order_seq_cst</tt></td>
-<td>the operation has both acquire and release semantics,
- and, in addition, has sequentially-consistent operation ordering</td>
-</tr>
-</tbody></table>
-</blockquote>
-
-<p>
-So that seems to be "the same thing" as <tt>memory_order_acq_rel</tt>, with additional
-constraints.
-</p>
-
-<p>
-I'm then reading p2, where it says:
-</p>
-
-<blockquote>
-The <tt>memory_order_seq_cst</tt> operations that load a value are acquire operations
-on the affected locations. The <tt>memory_order_seq_cst</tt> operations that store a value
-are release operations on the affected locations.
-</blockquote>
-
-<p>
-That seems to imply that atomic reads only have acquire semantics. If that
-is intended, does this also apply to <tt>memory_order_acq_rel</tt> and the individual
-load/store operations as well?
-</p>
-
-<p>
-Also, the table in p1 contains phrases with "thus" that seem to indicate
-consequences of normative wording in 1.10 [intro.multithread]. That shouldn't be in
-normative text, for the fear of redundant or inconsistent specification with
-the other normative text.
-</p>
-
-<p>
-Double-check 29.4 [atomics.types.operations] that each
-operation clearly says whether it's a load or a store operation, or
-both. (It could be clearer, IMO. Solution not in current proposed resolution.)
-</p>
-
-<p>
-29.1 [atomics.order] p2: What's a "consistent execution"? It's not defined in
-1.10 [intro.multithread], it's just used in notes there.
-</p>
-
-<p>
-And why does 29.4 [atomics.types.operations] p9 for "load" say:
-</p>
-
-
-<blockquote>
-<i>Requires:</i> The order argument shall not be <tt>memory_order_acquire</tt>
-nor <tt>memory_order_acq_rel</tt>.
-</blockquote>
-
-<p>
-(Since this is exactly the same restriction as for "store", it seems to be a typo.)
-</p>
-
-<p>
-And then: 29.4 [atomics.types.operations] p12:
-</p>
-
-<blockquote>
-These operations are read-modify-write operations in the sense of the
-"synchronizes with" definition (1.10 [intro.multithread]), so both such an operation and the
-evaluation that produced the input value synchronize with any evaluation
-that reads the updated value.
-</blockquote>
-
-<p>
-This is redundant with 1.10 [intro.multithread], see above for the reasoning.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Replace the cross-reference in p1 to refer to 1.1 [intro.scope] instead of
-1.7 [intro.memory].
-Rephrase the table in as follows (maybe don't use a table):
-</p>
-
-<blockquote>
-<p>
-For <tt>memory_order_relaxed</tt>, no operation orders memory.
-</p>
-
-<p>
-For <tt>memory_order_release</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
-a store operation performs a release operation on the affected memory location.
-</p>
-
-<p>
-For <tt>memory_order_acquire</tt>, <tt>memory_order_acq_rel</tt>, and <tt>memory_order_seq_cst</tt>,
-a load operation performs an acquire operation on the affected memory location.
-</p>
-</blockquote>
-
-<p>
-Rephrase 29.1 [atomics.order] p2:
-</p>
-
-<blockquote>
-<del>The <tt>memory_order_seq_cst</tt> operations that load a value are
-acquire operations on the affected locations. The
-<tt>memory_order_seq_cst</tt> operations that store a value are release
-operations on the affected locations.</del>
-<del>In addition, in a consistent
-execution, t</del><ins>T</ins>here <del>must be</del> <ins>is</ins> a single
-total order <tt>S</tt> on all
-<tt>memory_order_seq_cst</tt> operations, consistent with the happens before
-order and modification orders for all affected locations, such that each
-<tt>memory_order_seq_cst</tt> operation observes either the last preceding
-modification according to this order <tt>S</tt>, or the result of an operation
-that is not <tt>memory_order_seq_cst</tt>. [<i>Note:</i> Although it is not explicitly
-required that <tt>S</tt> include locks, it can always be extended to an order
-that does include lock and unlock operations, since the ordering between
-those is already included in the happens before ordering. <i>-- end note</i>]
-</blockquote>
-
-<p>
-Rephrase 29.4 [atomics.types.operations] p12 as:
-</p>
-
-<blockquote>
-<i>Effects:</i> Atomically replaces the value pointed to by object or by
-this with desired. Memory is affected according to the value of order.
-These operations are read-modify-write operations <del>in the sense of the
-"synchronizes with" definition</del> (1.10 [intro.multithread])<del>, so both such an operation and the
-evaluation that produced the input value synchronize with any evaluation
-that reads the updated value</del>.
-</blockquote>
-
-<p>
-Same in p15, p20, p22.
-</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="819"></a>819. rethrow_if_nested</h3>
-<p><b>Section:</b> 18.7.6 [except.nested] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-25</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Looking at the wording I submitted for <tt>rethrow_if_nested</tt>, I don't think I
-got it quite right.
-</p>
-
-<p>
-The current wording says:
-</p>
-
-<blockquote>
-<pre>template &lt;class E&gt; void rethrow_if_nested(const E&amp; e);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Calls <tt>e.rethrow_nested()</tt> only if <tt>e</tt>
-is publicly derived from <tt>nested_exception</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-This is trying to be a bit subtle, by requiring <tt>e</tt> (not <tt>E</tt>) to be publicly
-derived from <tt>nested_exception</tt> the idea is that a <tt>dynamic_cast</tt> would be
-required to be sure. Unfortunately, if <tt>e</tt> is dynamically but not statically
-derived from <tt>nested_exception</tt>, <tt>e.rethrow_nested()</tt> is ill-formed.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="820"></a>820. <tt>current_exception()</tt>'s interaction with throwing copy ctors</h3>
-<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Stephan T. Lavavej <b>Date:</b> 2008-03-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-As of N2521, the Working Paper appears to be silent about what
-<tt>current_exception()</tt> should do if it tries to copy the currently handled
-exception and its copy constructor throws. 18.7.5 [propagation]/7 says "If the
-function needs to allocate memory and the attempt fails, it returns an
-<tt>exception_ptr</tt> object that refers to an instance of <tt>bad_alloc</tt>.", but
-doesn't say anything about what should happen if memory allocation
-succeeds but the actual copying fails.
-</p>
-
-<p>
-I see three alternatives: (1) return an <tt>exception_ptr</tt> object that refers
-to an instance of some fixed exception type, (2) return an <tt>exception_ptr</tt>
-object that refers to an instance of the copy ctor's thrown exception
-(but if that has a throwing copy ctor, an infinite loop can occur), or
-(3) call <tt>terminate()</tt>.
-</p>
-
-<p>
-I believe that <tt>terminate()</tt> is the most reasonable course of action, but
-before we go implement that, I wanted to raise this issue.
-</p>
-
-<p><i>[
-Peter's summary:
-]</i></p>
-
-
-<blockquote>
-<p>
-The current practice is to not have throwing copy constructors in
-exception classes, because this can lead to <tt>terminate()</tt> as described in
-15.5.1 [except.terminate]. Thus calling <tt>terminate()</tt> in this situation seems
-consistent and does not introduce any new problems.
-</p>
-
-<p>
-However, the resolution of core issue 475 may relax this requirement:
-</p>
-
-<blockquote>
-The CWG agreed with the position that <tt>std::uncaught_exception()</tt> should
-return <tt>false</tt> during the copy to the exception object and that <tt>std::terminate()</tt>
-should not be called if that constructor exits with an exception.
-</blockquote>
-
-<p>
-Since throwing copy constructors will no longer call <tt>terminate()</tt>, option
-(3) doesn't seem reasonable as it is deemed too drastic a response in a
-recoverable situation.
-</p>
-
-<p>
-Option (2) cannot be adopted by itself, because a potential infinite
-recursion will need to be terminated by one of the other options.
-</p>
-
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following paragraph after 18.7.5 [propagation]/7:
-</p>
-
-<blockquote>
-<p>
-<i>Returns (continued):</i> If the attempt to copy the current exception
-object throws an exception, the function returns an <tt>exception_ptr</tt> that
-refers to the thrown exception or, if this is not possible, to an
-instance of <tt>bad_exception</tt>.
-</p>
-<p>
-[<i>Note:</i> The copy constructor of the thrown exception may also fail, so
-the implementation is allowed to substitute a <tt>bad_exception</tt> to avoid
-infinite recursion. <i>-- end note.</i>]
-</p>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="821"></a>821. Minor cleanup : <tt>unique_ptr</tt></h3>
-<p><b>Section:</b> 20.7.11.3.3 [unique.ptr.runtime.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-03-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Reading resolution of LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> I noticed the following:
-</p>
-
-<blockquote>
-<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-</pre>
-
-<p>
--1- <i>Requires:</i> Does not accept pointer types which are convertible
-to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
-required). [<i>Note:</i> One implementation technique is to create a private
-templated overload. <i>-- end note</i>]
-</p>
-</blockquote>
-
-<p>
-This could be cleaned up by mandating the overload as a public deleted
-function. In addition, we should probably overload <tt>reset</tt> on <tt>nullptr_t</tt>
-to be a stronger match than the deleted overload. Words...
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to class template definition in 20.7.11.3 [unique.ptr.runtime]
-</p>
-
-<blockquote>
-<pre>// modifiers
-T* release();
-void reset(T* p = 0);
-<ins>void reset( nullptr_t );</ins>
-<ins>template&lt; typename T &gt; void reset( T ) = delete;</ins>
-void swap(unique_ptr&amp;&amp; u);
-</pre>
-</blockquote>
-
-<p>
-Update 20.7.11.3.3 [unique.ptr.runtime.modifiers]
-</p>
-
-<blockquote>
-<pre>void reset(pointer p = pointer());
-<ins>void reset(nullptr_t);</ins>
-</pre>
-
-<p>
-<del>-1- <i>Requires:</i> Does not accept pointer types which are convertible
-to <tt>pointer</tt> (diagnostic
-required). [<i>Note:</i> One implementation technique is to create a private
-templated overload. <i>-- end note</i>]</del>
-</p>
-<p>
-<i>Effects:</i> If <tt>get() == nullptr</tt> there are no effects. Otherwise <tt>get_deleter()(get())</tt>.
-</p>
-<p>...</p>
-</blockquote>
-
-<p><i>[
-Note this wording incorporates resolutions for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a> (New) and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (Ready).
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="822"></a>822. Object with explicit copy constructor no longer <tt>CopyConstructible</tt></h3>
-<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> James Kanze <b>Date:</b> 2008-04-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I just noticed that the following program is legal in C++03, but
-is forbidden in the current draft:
-</p>
-
-<blockquote><pre>#include &lt;vector&gt;
-#include &lt;iostream&gt;
-
-class Toto
-{
-public:
- Toto() {}
- explicit Toto( Toto const&amp; ) {}
-} ;
-
-int
-main()
-{
- std::vector&lt; Toto &gt; v( 10 ) ;
- return 0 ;
-}
-</pre></blockquote>
-
-<p>
-Is this change intentional? (And if so, what is the
-justification? I wouldn't call such code good, but I don't see
-any reason to break it unless we get something else in return.)
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.1.1 [utility.arg.requirements] change Table 33: <tt>MoveConstructible</tt> requirements [moveconstructible]:
-</p>
-
-<blockquote>
-<table border="1">
-<tbody><tr>
-<th>expression</th><th>post-condition</th>
-</tr>
-<tr>
-<td><tt>T t<ins>(rv)</ins><del> = rv</del></tt></td><td><tt>t</tt> is equivalent to the value of <tt>rv</tt> before the construction</td>
-</tr>
-<tr>
-<td colspan="2" align="center">...</td>
-</tr>
-</tbody></table>
-</blockquote>
-
-<p>
-In 20.1.1 [utility.arg.requirements] change Table 34: <tt>CopyConstructible</tt> requirements [copyconstructible]:
-</p>
-
-<blockquote>
-<table border="1">
-<tbody><tr>
-<th>expression</th><th>post-condition</th>
-</tr>
-<tr>
-<td><tt>T t<ins>(u)</ins><del> = u</del></tt></td><td>the value of <tt>u</tt> is unchanged and is equivalent to <tt>t</tt></td>
-</tr>
-<tr>
-<td colspan="2" align="center">...</td>
-</tr>
-</tbody></table>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="823"></a>823. <tt>identity&lt;void&gt;</tt> seems broken</h3>
-<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2008-04-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-N2588 seems to have added an <tt>operator()</tt> member function to the
-<tt>identity&lt;&gt;</tt> helper in 20.2.2 [forward]. I believe this change makes it no
-longer possible to instantiate <tt>identity&lt;void&gt;</tt>, as it would require
-forming a reference-to-<tt>void</tt> type as this <tt>operator()</tt>'s parameter type.
-</p>
-
-<p>
-Suggested resolution: Specialize <tt>identity&lt;void&gt;</tt> so as not to require
-the member function's presence.
-</p>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-Jens: suggests to add a requires clause to avoid specializing on <tt>void</tt>.
-</p>
-<p>
-Alisdair: also consider cv-qualified <tt>void</tt>.
-</p>
-<p>
-Alberto provided proposed wording.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change definition of <tt>identity</tt> in 20.2.2 [forward], paragraph 2, to:
-</p>
-
-<blockquote><pre>template &lt;class T&gt; struct identity {
- typedef T type;
-
- <ins>requires ReferentType&lt;T&gt;</ins>
- const T&amp; operator()(const T&amp; x) const;
- };
-</pre></blockquote>
-<p>...</p>
-<blockquote><pre> <ins>requires ReferentType&lt;T&gt;</ins>
- const T&amp; operator()(const T&amp; x) const;
-</pre></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>
-The point here is to able to write <tt>T&amp;</tt> given <tt>T</tt> and <tt>ReferentType</tt> is
-precisely the concept that guarantees so, according to N2677
-(Foundational concepts). Because of this, it seems preferable than an
-explicit check for <tt>cv void</tt> using <tt>SameType/remove_cv</tt> as it was suggested
-in Sophia. In particular, Daniel remarked that there may be types other
-than <tt>cv void</tt> which aren't referent types (<tt>int[]</tt>, perhaps?).
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="824"></a>824. rvalue ref issue with <tt>basic_string</tt> inserter</h3>
-<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In the current working paper, the <tt>&lt;string&gt;</tt> header synopsis at the end of
-21.2 [string.classes] lists a single <tt>operator&lt;&lt;</tt> overload
-for <tt>basic_string</tt>.
-</p>
-
-<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
- operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
- const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
-</pre></blockquote>
-
-<p>
-The definition in 21.3.8.9 [string.io] lists two:
-</p>
-
-<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
- operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
- const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
-
-template&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
- operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
- const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
-</pre></blockquote>
-
-<p>
-I believe the synopsis in 21.2 [string.classes] is correct, and the first of the two
-signatures in 21.3.8.9 [string.io] should be deleted.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Delete the first of the two signatures in 21.3.8.9 [string.io]:
-</p>
-
-<blockquote><pre><del>template&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
- operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
- const basic_string&lt;charT,traits,Allocator&gt;&amp; str);</del>
-
-template&lt;class charT, class traits, class Allocator&gt;
- basic_ostream&lt;charT, traits&gt;&amp;
- operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os,
- const basic_string&lt;charT,traits,Allocator&gt;&amp; str);
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="825"></a>825. Missing rvalues reference stream insert/extract operators?</h3>
-<p><b>Section:</b> 19.4.2.1 [syserr.errcode.overview], 20.7.12.2.8
-[util.smartptr.shared.io], 22.2.8 [facets.examples], 23.3.5.3
-[bitset.operators], 26.3.6 [complex.ops], 27.5 [stream.buffers], 28.9
-[re.submatch] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-04-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Should the following use rvalues references to stream in insert/extract
-operators?
-</p>
-
-<ul>
-<li>19.4.2.1 [syserr.errcode.overview]</li>
-<li>20.7.12.2.8 [util.smartptr.shared.io]</li>
-<li>22.2.8 [facets.examples]</li>
-<li>23.3.5.3 [bitset.operators]</li>
-<li>26.3.6 [complex.ops]</li>
-<li>Doubled signatures in 27.5 [stream.buffers] for character inserters
-(ref 27.6.2.6.4 [ostream.inserters.character])
-+ definition 27.6.2.6.4 [ostream.inserters.character]</li>
-<li>28.9 [re.submatch]</li>
-</ul>
-
-<p><i>[
-Sophia Antipolis
-]</i></p>
-
-
-<blockquote>
-Agree with the idea in the issue, Alisdair to provide wording.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="827"></a>827. <tt>constexpr shared_ptr::shared_ptr()?</tt></h3>
-<p><b>Section:</b> 20.7.12.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Would anyone object to making the default constructor of <tt>shared_ptr</tt> (and
-<tt>weak_ptr</tt> and <tt>enable_shared_from_this) constexpr</tt>? This would enable
-static initialization for <tt>shared_ptr</tt> variables, eliminating another
-unfair advantage of raw pointers.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="828"></a>828. Static initialization for <tt>std::mutex</tt>?</h3>
-<p><b>Section:</b> 30.3.1.1 [thread.mutex.class] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-[Note: I'm assuming here that 3.6.2 [basic.start.init]/1 will be fixed.]
-</p>
-<p>
-Currently <tt>std::mutex</tt> doesn't support static initialization. This is a
-regression with respect to <tt>pthread_mutex_t</tt>, which does. I believe that
-we should strive to eliminate such regressions in expressive power where
-possible, both to ease migration and to not provide incentives to (or
-force) people to forego the C++ primitives in favor of pthreads.
-</p>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-We believe this is implementable on POSIX, because the initializer-list
-feature and the constexpr feature make this work. Double-check core
-language about static initialization for this case. Ask core for a core
-issue about order of destruction of statically-initialized objects wrt.
-dynamically-initialized objects (should come afterwards). Check
-non-POSIX systems for implementability.
-</p>
-<p>
-If ubiquitous implementability cannot be assured, plan B is to introduce
-another constructor, make this constexpr, which is
-conditionally-supported. To avod ambiguities, this new constructor needs
-to have an additional parameter.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 30.3.1.1 [thread.mutex.class]:
-</p>
-
-<blockquote><pre>class mutex {
-public:
- <ins>constexpr</ins> mutex();
- ...
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="829"></a>829. current_exception wording unclear about exception type</h3>
-<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-04-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Consider this code:</p>
-
-<blockquote>
-<pre>exception_ptr xp;</pre>
-<pre>try {do_something(); }
-
-catch (const runtime_error&amp; ) {xp = current_exception();}
-
-...
-
-rethrow_exception(xp);</pre>
-</blockquote>
-
-<p>
-Say <code>do_something()</code> throws an exception object of type <code>
-range_error</code>. What is the type of the exception object thrown by <code>
-rethrow_exception(xp)</code> above? It must have a type of <code>range_error</code>;
-if it were of type <code>runtime_error</code> it still isn't possible to
-propagate an exception and the exception_ptr/current_exception/rethrow_exception
-machinery serves no useful purpose.
-</p>
-
-<p>
-Unfortunately, the current wording does not explicitly say that. Different
-people read the current wording and come to different conclusions. While it may
-be possible to deduce the correct type from the current wording, it would be
-much clearer to come right out and explicitly say what the type of the referred
-to exception is.
-</p>
-
-<p><i>[
-Peter adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-I don't like the proposed resolution of 829. The normative text is
-unambiguous that the <tt>exception_ptr</tt> refers to the <em>currently handled
-exception</em>. This term has a standard meaning, see 15.3 [except.handle]/8; this is the
-exception that <tt>throw;</tt> would rethrow, see 15.1 [except.throw]/7.
-</p>
-<p>
-A better way to address this is to simply add the non-normative example
-in question as a clarification. The term <i>currently handled exception</i>
-should be italicized and cross-referenced. A [<i>Note:</i> the currently
-handled exception is the exception that a throw expression without an
-operand (15.1 [except.throw]/7) would rethrow. <i>--end note</i>] is also an option.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-After 18.7.5 [propagation] , paragraph 7, add the indicated text:
-</p>
-
-<blockquote>
-<pre>exception_ptr current_exception();</pre>
-
-<blockquote>
-<p>
-<i>Returns:</i> <code>exception_ptr</code> object that refers
-to the currently handled exception <ins>(15.3 [except.handle])</ins> or a copy of the currently handled
-exception, or a null <code>exception_ptr</code> object if no exception is being handled. If
-the function needs to allocate memory and the attempt fails, it returns an
-<code>exception_ptr</code> object that refers to an instance of <code>bad_alloc</code>.
-It is unspecified whether the return values of two successive calls to
-<code>current_exception</code> refer to the same exception object.
-[<i>Note:</i> that is, it
-is unspecified whether <code>current_exception</code>
-creates a new copy each time it is called.
-<i>-- end note</i>]
-</p>
-
-<p>
-<i>Throws:</i> nothing.
-</p>
-
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="830"></a>830. Incomplete list of char_traits specializations</h3>
-<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 2008-04-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
- Paragraph 4 of 21.1 [char.traits] mentions that this
- section specifies two specializations (<code>char_traits&lt;char&gt;</code>
- and (<code>char_traits&lt;wchar_t&gt;</code>). However, there are actually
- four specializations provided, i.e. in addition to the two above also
- <code>char_traits&lt;char16_t&gt;</code> and <code>char_traits&lt;char32_t&gt;</code>).
- I guess this was just an oversight and there is nothing wrong with just
- fixing this.
-</p>
-
-<p><i>[
-Alisdair adds:
-]</i></p>
-
-<blockquote>
-<tt>char_traits&lt; char16/32_t &gt;</tt>
-should also be added to <tt>&lt;ios_fwd&gt;</tt> in 27.2 [iostream.forward], and all the specializations
-taking a <tt>char_traits</tt> parameter in that header.
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-Idea of the issue is ok.
-</p>
-<p>
-Alisdair to provide wording, once that wording arrives, move to review.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
- Replace paragraph 4 of 21.1 [char.traits] by:
-</p>
-<blockquote>
-<p>
- This subclause specifies a struct template, <code>char_traits&lt;charT&gt;</code>,
- and four explicit specializations of it, <code>char_traits&lt;char&gt;</code>,
- <code>char_traits&lt;char16_t&gt;</code>, <code>char_traits&lt;char32_t&gt;</code>, and
- <code>char_traits&lt;wchar_t&gt;</code>, all of which appear in the header
- &lt;string&gt; and satisfy the requirements below.
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="832"></a>832. Applying constexpr to System error support</h3>
-<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Initialization of objects of class <tt>error_code</tt>
-(19.4.2 [syserr.errcode]) and class
-<tt>error_condition</tt> (19.4.3 [syserr.errcondition]) can be made simpler and more reliable by use of
-the new <tt>constexpr</tt> feature
-[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2349.pdf">N2349</a>]
-of C++0x. Less code will need to be
-generated for both library implementations and user programs when
-manipulating constant objects of these types.
-</p>
-
-<p>
-This was not proposed originally because the constant expressions
-proposal was moving into the standard at about the same time as the
-Diagnostics Enhancements proposal
-[<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>],
-and it wasn't desirable to
-make the later depend on the former. There were also technical concerns
-as to how <tt>constexpr</tt> would apply to references. Those concerns are now
-resolved; <tt>constexpr</tt> can't be used for references, and that fact is
-reflected in the proposed resolution.
-</p>
-
-<p>
-Thanks to Jens Maurer, Gabriel Dos Reis, and Bjarne Stroustrup for clarification of <tt>constexpr</tt> requirements.
-</p>
-
-<p>
-LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> is related in that it raises the question of whether the
-exposition only member <tt>cat_</tt> of class <tt>error_code</tt> (19.4.2 [syserr.errcode]) and class
-<tt>error_condition</tt> (19.4.3 [syserr.errcondition]) should be presented as a reference or pointer.
-While in the context of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a> that is arguably an editorial question,
-presenting it as a pointer becomes more or less required with this
-proposal, given <tt>constexpr</tt> does not play well with references. The
-proposed resolution thus changes the private member to a pointer, which
-also brings it in sync with real implementations.
-</p>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-On going question of extern pointer vs. inline functions for interface.
-</blockquote>
-
-<p><i>[
-Pre-San Francisco:
-]</i></p>
-
-
-<blockquote>
-<p>
-Beman Dawes reports that this proposal is unimplementable, and thus NAD.
-</p>
-<p>
-Implementation would require <tt>constexpr</tt> objects of classes derived
-from class <tt>error_category</tt>, which has virtual functions, and that is
-not allowed by the core language. This was determined when trying to
-implement the proposal using a constexpr enabled compiler provided
-by Gabriel Dos Reis, and subsequently verified in discussions with
-Gabriel and Jens Maurer.
-</p>
-
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-The proposed wording assumes the LWG <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> proposed wording has been
-applied to the WP, resulting in the former <tt>posix_category</tt> being renamed
-<tt>generic_category</tt>. If <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a> has not been applied, the names in this
-proposal must be adjusted accordingly.
-</p>
-
-<p>
-Change 19.4.1.1 [syserr.errcat.overview] Class
-<tt>error_category</tt> overview <tt>error_category</tt> synopsis as
-indicated:
-</p>
-
-<blockquote><pre><del>const error_category&amp; get_generic_category();</del>
-<del>const error_category&amp; get_system_category();</del>
-
-<del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> generic_category<del> = get_generic_category()</del>;
-<del>static</del> <ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>native_category</del> system_category<del> = get_system_category()</del>;
-</pre></blockquote>
-
-<p>
-Change 19.4.1.5 [syserr.errcat.objects] Error category objects as indicated:
-</p>
-
-<blockquote>
-<pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>generic_category<del>()</del>;
-</pre>
-<p>
-<del><i>Returns:</i> A reference</del> <ins><tt>generic_category</tt> shall point</ins>
-to <del>an</del> <ins>a statically initialized</ins> object of a type derived from
-class <tt>error_category</tt>.
-</p>
-
-<p>
-<del><i>Remarks:</i></del> The object's <tt>default_error_condition</tt> and <tt>equivalent</tt> virtual
-functions shall behave as specified for the class <tt>error_category</tt>. The
-object's <tt>name</tt> virtual function shall return a pointer to the string
-<tt>"GENERIC"</tt>.
-</p>
-
-<pre><ins>extern</ins> const error_category<del>&amp;</del><ins>* const</ins> <del>get_</del>system_category<del>()</del>;
-</pre>
-
-<p>
-<del><i>Returns:</i> A reference</del> <ins><tt>system_category</tt> shall point</ins>
-to <del>an</del> <ins>a statically
-initialized</ins> object of a type derived from class <tt>error_category</tt>.
-</p>
-
-<p>
-<del><i>Remarks:</i></del> The object's <tt>equivalent</tt> virtual functions shall behave as
-specified for class <tt>error_category</tt>. The object's <tt>name</tt> virtual function
-shall return a pointer to the string <tt>"system"</tt>. The object's
-<tt>default_error_condition</tt> virtual function shall behave as follows:
-</p>
-
-<p>
-If the argument <tt>ev</tt> corresponds to a POSIX <tt>errno</tt> value <tt>posv</tt>, the function
-shall return <tt>error_condition(posv, generic_category)</tt>. Otherwise, the
-function shall return <tt>error_condition(ev, system_category)</tt>. What
-constitutes correspondence for any given operating system is
-unspecified. [<i>Note:</i> The number of potential system error codes is large
-and unbounded, and some may not correspond to any POSIX <tt>errno</tt> value.
-Thus implementations are given latitude in determining correspondence.
-<i>-- end note</i>]
-</p>
-</blockquote>
-
-<p>
-Change 19.4.2.1 [syserr.errcode.overview] Class <tt>error_code</tt> overview as indicated:
-</p>
-
-<blockquote><pre>class error_code {
-public:
- ...;
- <ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
- ...
- void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
- ...
- const error_category<del>&amp;</del><ins>*</ins> category() const;
- ...
-private:
- int val_; // exposition only
- const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
-</pre></blockquote>
-
-<p>
-Change 19.4.2.2 [syserr.errcode.constructors] Class <tt>error_code</tt> constructors as indicated:
-</p>
-
-<blockquote>
-<pre><ins>constexpr</ins> error_code(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
-</pre>
-<p>
-<i>Effects:</i> Constructs an object of type <tt>error_code</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-
-<p>
-Change 19.4.2.3 [syserr.errcode.modifiers] Class <tt>error_code</tt> modifiers as indicated:
-</p>
-
-<blockquote>
-<pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
-</pre>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-
-<p>
-Change 19.4.2.4 [syserr.errcode.observers] Class <tt>error_code</tt> observers as indicated:
-</p>
-
-<blockquote>
-<pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
-</pre>
-
-<p>
-<i>Returns:</i> <tt>cat_</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-
-<p>
-Change 19.4.3.1 [syserr.errcondition.overview] Class <tt>error_condition</tt> overview as indicated:
-</p>
-
-<blockquote>
-<pre>class error_condition {
-public:
- ...;
- <ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
- ...
- void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
- ...
- const error_category<del>&amp;</del><ins>*</ins> category() const;
- ...
-private:
- int val_; // exposition only
- const error_category<del>&amp;</del><ins>*</ins> cat_; // exposition only
-</pre>
-</blockquote>
-
-<p>
-Change 19.4.3.2 [syserr.errcondition.constructors] Class <tt>error_condition</tt> constructors as indicated:
-</p>
-
-<blockquote>
-<pre><ins>constexpr</ins> error_condition(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
-</pre>
-<p>
-<i>Effects:</i> Constructs an object of type <tt>error_condition</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-
-<p>
-Change 19.4.3.3 [syserr.errcondition.modifiers] Class <tt>error_condition</tt> modifiers as indicated:
-</p>
-
-<blockquote>
-<pre>void assign(int val, const error_category<del>&amp;</del><ins>*</ins> cat);
-</pre>
-<p>
-<i>Postconditions:</i> <tt>val_ == val</tt> and <tt>cat_ == cat</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-
-<p>
-Change 19.4.3.4 [syserr.errcondition.observers] Class <tt>error_condition</tt> observers as indicated:
-</p>
-
-<blockquote>
-<pre>const error_category<del>&amp;</del><ins>*</ins> category() const;
-</pre>
-<p>
-<i>Returns:</i> <tt>cat_</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-</blockquote>
-
-<p>
-Throughout 19.4 [syserr] System error support, change "<tt>category().</tt>" to "<tt>category()-&gt;</tt>".
-Appears approximately six times.
-</p>
-
-<p>
-<i>[Partially Editorial]</i> In 19.4.4 [syserr.compare] Comparison operators,
-paragraphs 2 and 4, change "<tt>category.equivalent(</tt>" to
-"<tt>category()-&gt;equivalent(</tt>".
-</p>
-
-<p>
-Change 19.4.5.1 [syserr.syserr.overview] Class system_error overview as indicated:
-</p>
-
-<blockquote><pre>public:
- system_error(error_code ec, const string&amp; what_arg);
- system_error(error_code ec);
- system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat,
- const string&amp; what_arg);
- system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat);
-</pre></blockquote>
-
-<p>
-Change 19.4.5.2 [syserr.syserr.members] Class system_error members as indicated:
-</p>
-
-<blockquote>
-<pre>system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat, const string&amp; what_arg);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
-<tt>strcmp(runtime_error::what(), what_arg.c_str()) == 0</tt>.
-</p>
-</blockquote>
-
-<pre>system_error(int ev, const error_category<del>&amp;</del><ins>*</ins> ecat);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
-</p>
-<p>
-<i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and
-<tt>strcmp(runtime_error::what(), "") == 0</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="833"></a>833. Freestanding implementations header list needs review for C++0x</h3>
-<p><b>Section:</b> 17.4.1.3 [compliance] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-05-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Once the C++0x standard library is feature complete, the LWG needs to
-review 17.4.1.3 [compliance] Freestanding implementations header list to
-ensure it reflects LWG consensus.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="834"></a>834. Unique_ptr::pointer requirements underspecified</h3>
-<p><b>Section:</b> 20.7.11.2 [unique.ptr.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-05-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a> (including recent updates by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>) proposes a useful
-extension point for <tt>unique_ptr</tt> by granting support for an optional
-<tt>deleter_type::pointer</tt> to act as pointer-like replacement for <tt>element_type*</tt>
-(In the following: <tt>pointer</tt>).
-</p>
-<p>
-Unfortunately no requirements are specified for the type <tt>pointer</tt> which has
-impact on at least two key features of <tt>unique_ptr</tt>:
-</p>
-
-<ol>
-<li>Operational fail-safety.</li>
-<li>(Well-)Definedness of expressions.</li>
-</ol>
-
-<p>
-<tt>Unique_ptr</tt> specification makes great efforts to require that essentially *all*
-operations cannot throw and therefore adds proper wording to the affected
-operations of the deleter as well. If user-provided <tt>pointer</tt>-emulating types
-("smart pointers") will be allowed, either *all* throw-nothing clauses have to
-be replaced by weaker "An exception is thrown only if <tt>pointer</tt>'s {op} throws
-an exception"-clauses or it has to be said explicitly that all used
-operations of
-<tt>pointer</tt> are required *not* to throw. I understand the main focus of <tt>unique_ptr</tt>
-to be as near as possible to the advantages of native pointers which cannot
-fail and thus strongly favor the second choice. Also, the alternative position
-would make it much harder to write safe and simple template code for
-<tt>unique_ptr</tt>. Additionally, I assume that a general statement need to be given
-that all of the expressions of <tt>pointer</tt> used to define semantics are required to
-be well-formed and well-defined (also as back-end for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>).
-</p>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-Howard: We maybe need a core concept <tt>PointerLike</tt>, but we don't need the
-arithmetic (see <tt>shared_ptr</tt> vs. <tt>vector&lt;T&gt;::iterator</tt>.
-</p>
-<p>
-Howard will go through and enumerate the individual requirements wrt. <tt>pointer</tt> for each member function.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following sentence just at the end of the newly proposed
-20.7.11.2 [unique.ptr.single]/p. 3:
-</p>
-
-<blockquote>
-<tt>unique_ptr&lt;T, D&gt;::pointer</tt>'s operations shall be well-formed, shall have well
-defined behavior, and shall not throw exceptions.
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="835"></a>835. tying two streams together (correction to DR 581)</h3>
-<p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The fix for
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>,
-now integrated into the working paper, overlooks a couple of minor
-problems.
-
- </p>
- <p>
-
-First, being an unformatted function once again, <code>flush()</code>
-is required to create a sentry object whose constructor must, among
-other things, flush the tied stream. When two streams are tied
-together, either directly or through another intermediate stream
-object, flushing one will also cause a call to <code>flush()</code> on
-the other tied stream(s) and vice versa, ad infinitum. The program
-below demonstrates the problem.
-
- </p>
- <p>
-
-Second, as Bo Persson notes in his
-comp.lang.c++.moderated <a href="http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/f2187794e9cc036d/305df31dc583054a">post</a>,
-for streams with the <code>unitbuf</code> flag set such
-as <code>std::stderr</code>, the destructor of the sentry object will
-again call <code>flush()</code>. This seems to create an infinite
-recursion for <code>std::cerr &lt;&lt; std::flush;</code>
-
- </p>
- <blockquote>
- <pre>#include &lt;iostream&gt;
-
-int main ()
-{
- std::cout.tie (&amp;std::cerr);
- std::cerr.tie (&amp;std::cout);
- std::cout &lt;&lt; "cout\n";
- std::cerr &lt;&lt; "cerr\n";
-}
- </pre>
- </blockquote>
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-I think an easy way to plug the first hole is to add a requires clause
-to <code>ostream::tie(ostream *tiestr)</code> requiring the this
-pointer not be equal to any pointer on the list starting
-with <code>tiestr-&gt;tie()</code>
-through <code>tiestr()-&gt;tie()-&gt;tie()</code> and so on. I am not
-proposing that we require implementations to traverse this list,
-although I think we could since the list is unlikely to be very long.
-
- </p>
- <p>
-
-Add a <i>Requires</i> clause to 27.4.4.2 [basic.ios.members] withethe following
-text:
-
- </p>
- <blockquote>
-
-<i>Requires:</i> If <code>(tiestr != 0)</code> is
-true, <code>tiestr</code> must not be reachable by traversing the
-linked list of tied stream objects starting
-from <code>tiestr-&gt;tie()</code>.
-
- </blockquote>
- <p>
-
-In addition, to prevent the infinite recursion that Bo writes about in
-his comp.lang.c++.moderated post, I propose to change
-27.6.2.4 [ostream::sentry], p2 like so:
-
- </p>
- <blockquote>
-
-If <code>((os.flags() &amp; ios_base::unitbuf) &amp;&amp;
-!uncaught_exception())</code> is true,
-calls <del>os.flush()</del> <ins><code>os.rdbuf()-&gt;pubsync()</code></ins>.
-
- </blockquote>
-
-
-
-
-<hr>
-<h3><a name="836"></a>836.
- effects of <code>money_base::space</code> and
- <code>money_base::none</code> on <code>money_get</code>
- </h3>
-<p><b>Section:</b> 22.2.6.1.2 [locale.money.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.money.get.virtuals">active issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.money.get.virtuals">issues</a> in [locale.money.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a></p>
-<p><b>Discussion:</b></p>
- <p>
-
-In paragraph 2, 22.2.6.1.2 [locale.money.get.virtuals] specifies the following:
-
- </p>
- <blockquote>
-
-Where <code>space</code> or <code>none</code> appears in the format
-pattern, except at the end, optional white space (as recognized
-by <code>ct.is</code>) is consumed after any required space.
-
- </blockquote>
- <p>
-
-This requirement can be (and has been) interpreted two mutually
-exclusive ways by different readers. One possible interpretation
-is that:
-
- </p>
- <blockquote>
- <ol>
- <li>
-
-where <code>money_base::space</code> appears in the format, at least
-one space is required, and
-
- </li>
- <li>
-
-where <code>money_base::none</code> appears in the format, space is
-allowed but not required.
-
- </li>
- </ol>
- </blockquote>
- <p>
-
-The other is that:
-
- </p>
- <blockquote>
-
-where either <code>money_base::space</code> or <code>money_base::none</code> appears in the format, white space is optional.
-
- </blockquote>
-
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-I propose to change the text to make it clear that the first
-interpretation is intended, that is, to make following change to
-22.2.6.1.2 [locale.money.get.virtuals], p2:
-
- </p>
-
- <blockquote>
-
-When <code><ins>money_base::</ins>space</code>
-or <code><ins>money_base::</ins>none</code> appears <ins>as the last
-element </ins>in the format pattern, <del>except at the end, optional
-white space (as recognized by <code>ct.is</code>) is consumed after
-any required space.</del> <ins>no white space is consumed. Otherwise,
-where <code>money_base::space</code> appears in any of the initial
-elements of the format pattern, at least one white space character is
-required. Where <code>money_base::none</code> appears in any of the
-initial elements of the format pattern, white space is allowed but not
-required. In either case, any required followed by all optional white
-space (as recognized by <code>ct.is()</code>) is consumed.</ins>
-If <code>(str.flags() &amp; str.showbase)</code> is <code>false</code>, ...
-
- </blockquote>
-
-
-
-
-<hr>
-<h3><a name="837"></a>837.
- <code>basic_ios::copyfmt()</code> overly loosely specified
- </h3>
-<p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The <code>basic_ios::copyfmt()</code> member function is specified in 27.4.4.2 [basic.ios.members] to have the following effects:
-
- </p>
- <blockquote>
-
-<i>Effects</i>: If <code>(this == &amp;rhs)</code> does
-nothing. Otherwise assigns to the member objects of <code>*this</code>
-the corresponding member objects of <code>rhs</code>, except that
-
- <ul>
- <li>
-
-<code>rdstate()</code> and <code>rdbuf()</code> are left unchanged;
-
- </li>
- <li>
-
-<code>exceptions()</code> is altered last by
-calling <code>exceptions(rhs.except)</code>
-
- </li>
- <li>
-
-the contents of arrays pointed at by <code>pword</code>
-and <code>iword</code> are copied not the pointers themselves
-
- </li>
- </ul>
- </blockquote>
- <p>
-
-Since the rest of the text doesn't specify what the member objects
-of <code>basic_ios</code> are this seems a little too loose.
-
- </p>
-
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-I propose to tighten things up by adding a <i>Postcondition</i> clause
-to the function like so:
-
- </p>
- <blockquote>
- <i>Postconditions:</i>
-
- <table border="1">
- <thead>
- <tr>
- <th colspan="2"><code>copyfmt()</code> postconditions</th>
- </tr>
- <tr>
- <th>Element</th>
- <th>Value</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td><code>rdbuf()</code></td>
- <td><i>unchanged</i></td>
- </tr>
- <tr>
- <td><code>tie()</code></td>
- <td><code>rhs.tie()</code></td>
- </tr>
- <tr>
- <td><code>rdstate()</code></td>
- <td><i>unchanged</i></td>
- </tr>
- <tr>
- <td><code>exceptions()</code></td>
- <td><code>rhs.exceptions()</code></td>
- </tr>
- <tr>
- <td><code>flags()</code></td>
- <td><code>rhs.flags()</code></td>
- </tr>
- <tr>
- <td><code>width()</code></td>
- <td><code>rhs.width()</code></td>
- </tr>
- <tr>
- <td><code>precision()</code></td>
- <td><code>rhs.precision()</code></td>
- </tr>
- <tr>
- <td><code>fill()</code></td>
- <td><code>rhs.fill()</code></td>
- </tr>
- <tr>
- <td><code>getloc()</code></td>
- <td><code>rhs.getloc()</code></td>
- </tr>
- </tbody>
- </table>
- </blockquote>
- <p>
-
-The format of the table follows Table 117 (as
-of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2588.pdf">N2588</a>): <code>basic_ios::init()</code>
-effects.
-
- </p>
- <p>
-
-The intent of the new table is not to impose any new requirements or
-change existing ones, just to be more explicit about what I believe is
-already there.
-
- </p>
-
-
-
-
-<hr>
-<h3><a name="838"></a>838.
- can an <i>end-of-stream</i> iterator become a <i>non-end-of-stream</i> one?
- </h3>
-<p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-From message c++std-lib-20003...
-
- </p>
- <p>
-
-The description of <code>istream_iterator</code> in
-24.5.1 [istream.iterator], p1 specifies that objects of the
-class become the <i>end-of-stream</i> (EOS) iterators under the
-following condition (see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a> another problem
-with this paragraph):
-
- </p>
- <blockquote>
-
-If the end of stream is reached (<code>operator void*()</code> on the
-stream returns <code>false</code>), the iterator becomes equal to
-the <i>end-of-stream</i> iterator value.
-
- </blockquote>
- <p>
-
-One possible implementation approach that has been used in practice is
-for the iterator to set its <code>in_stream</code> pointer to 0 when
-it reaches the end of the stream, just like the default ctor does on
-initialization. The problem with this approach is that
-the <i>Effects</i> clause for <code>operator++()</code> says the
-iterator unconditionally extracts the next value from the stream by
-evaluating <code>*in_stream &gt;&gt; value</code>, without checking
-for <code>(in_stream == 0)</code>.
-
- </p>
- <p>
-
-Conformance to the requirement outlined in the <i>Effects</i> clause
-can easily be verified in programs by setting <code>eofbit</code>
-or <code>failbit</code> in <code>exceptions()</code> of the associated
-stream and attempting to iterate past the end of the stream: each
-past-the-end access should trigger an exception. This suggests that
-some other, more elaborate technique might be intended.
-
- </p>
- <p>
-
-Another approach, one that allows <code>operator++()</code> to attempt
-to extract the value even for EOS iterators (just as long
-as <code>in_stream</code> is non-0) is for the iterator to maintain a
-flag indicating whether it has reached the end of the stream. This
-technique would satisfy the presumed requirement implied by
-the <i>Effects</i> clause mentioned above, but it isn't supported by
-the exposition-only members of the class (no such flag is shown). This
-approach is also found in existing practice.
-
- </p>
- <p>
-
-The inconsistency between existing implementations raises the question
-of whether the intent of the specification is that a non-EOS iterator
-that has reached the EOS become a non-EOS one again after the
-stream's <code>eofbit</code> flag has been cleared? That is, are the
-assertions in the program below expected to pass?
-
- </p>
- <blockquote>
- <pre> sstream strm ("1 ");
- istream_iterator eos;
- istream_iterator it (strm);
- int i;
- i = *it++
- assert (it == eos);
- strm.clear ();
- strm &lt;&lt; "2 3 ";
- assert (it != eos);
- i = *++it;
- assert (3 == i);
- </pre>
- </blockquote>
- <p>
-
-Or is it intended that once an iterator becomes EOS it stays EOS until
-the end of its lifetime?
-
- </p>
-
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-The discussion of this issue on the reflector suggests that the intent
-of the standard is for an <code>istreambuf_iterator</code> that has
-reached the EOS to remain in the EOS state until the end of its
-lifetime. Implementations that permit EOS iterators to return to a
-non-EOS state may only do so as an extension, and only as a result of
-calling <code>istream_iterator</code> member functions on EOS
-iterators whose behavior is in this case undefined.
-
- </p>
- <p>
-
-To this end we propose to change 24.5.1 [istream.iterator], p1,
-as follows:
-
- </p>
- <blockquote>
-
-The result of operator-&gt; on an end<ins>-</ins>of<ins>-</ins>stream
-is not defined. For any other iterator value a <code>const T*</code>
-is returned.<ins> Invoking <code>operator++()</code> on
-an <i>end-of-stream</i> iterator is undefined.</ins> It is impossible
-to store things into istream iterators...
-
- </blockquote>
- <p>
-
-Add pre/postconditions to the member function descriptions of <code>istream_iterator</code> like so:
-
- </p>
- <blockquote>
-
-<pre>istream_iterator();</pre>
-
-<i>Effects</i>: Constructs the <i>end-of-stream</i> iterator.<br>
-<ins><i>Postcondition</i>: <code>in_stream == 0</code>.</ins>
-
-<pre>istream_iterator(istream_type &amp;s);</pre>
-
-<i>Effects</i>: Initializes <code>in_stream</code> with &amp;s. value
-may be initialized during construction or the first time it is
-referenced.<br>
-<ins><i>Postcondition</i>: <code>in_stream == &amp;s</code>.</ins>
-
-<pre>istream_iterator(const istream_iterator &amp;x);</pre>
-
-<i>Effects</i>: Constructs a copy of <code>x</code>.<br>
-<ins><i>Postcondition</i>: <code>in_stream == x.in_stream</code>.</ins>
-
-<pre>istream_iterator&amp; operator++();</pre>
-
-<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
-<i>Effects</i>: <code>*in_stream &gt;&gt; value</code>.
-
-<pre>istream_iterator&amp; operator++(int);</pre>
-
-<ins><i>Requires</i>: <code>in_stream != 0</code>.</ins><br>
-<i>Effects</i>:
- <blockquote><pre>istream_iterator tmp (*this);
-*in_stream &gt;&gt; value;
-return tmp;
- </pre>
- </blockquote>
- </blockquote>
-
-
-
-
-<hr>
-<h3><a name="839"></a>839. Maps and sets missing splice operation</h3>
-<p><b>Section:</b> 23.3 [associative], 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>
- <b>Submitter:</b> Alan Talbot <b>Date:</b> 2008-05-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Open">Open</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Splice is a very useful feature of <tt>list</tt>. This functionality is also very
-useful for any other node based container, and I frequently wish it were
-available for maps and sets. It seems like an omission that these
-containers lack this capability. Although the complexity for a splice is
-the same as for an insert, the actual time can be much less since the
-objects need not be reallocated and copied. When the element objects are
-heavy and the compare operations are fast (say a <tt>map&lt;int, huge_thingy&gt;</tt>)
-this can be a big win.
-</p>
-
-<p>
-<b>Suggested resolution:</b>
-</p>
-
-<p>
-Add the following signatures to map, set, multimap, multiset, and the unordered associative containers:
-</p>
-<blockquote><pre>
-void splice(list&lt;T,Allocator&gt;&amp;&amp; x);
-void splice(list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
-void splice(list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator first, const_iterator last);
-</pre></blockquote>
-
-<p>
-Hint versions of these are also useful to the extent hint is useful.
-(I'm looking for guidance about whether hints are in fact useful.)
-</p>
-
-<blockquote><pre>
-void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x);
-void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator i);
-void splice(const_iterator position, list&lt;T,Allocator&gt;&amp;&amp; x, const_iterator first, const_iterator last);
-</pre></blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-Don't try to <tt>splice "list"</tt> into the other containers, it should be container-type.
-</p>
-<p>
-<tt>forward_list</tt> already has <tt>splice_after</tt>.
-</p>
-<p>
-Would "<tt>splice</tt>" make sense for an <tt>unordered_map</tt>?
-</p>
-<p>
-Jens, Robert: "<tt>splice</tt>" is not the right term, it implies maintaining ordering in <tt>list</tt>s.
-</p>
-<p>
-Howard: <tt>adopt</tt>?
-</p>
-<p>
-Jens: <tt>absorb</tt>?
-</p>
-<p>
-Alan: <tt>subsume</tt>?
-</p>
-<p>
-Robert: <tt>recycle</tt>?
-</p>
-<p>
-Howard: <tt>transfer</tt>? (but no direction)
-</p>
-<p>
-Jens: <tt>transfer_from</tt>. No.
-</p>
-<p>
-Alisdair: Can we give a nothrow guarantee? If your <tt>compare()</tt> and <tt>hash()</tt> doesn't throw, yes.
-</p>
-<p>
-Daniel: For <tt>unordered_map</tt>, we can't guarantee nothrow.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="841"></a>841. cstdint.syn inconsistent with C99</h3>
-<p><b>Section:</b> 18.3.1 [cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-05-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-In specifying the names of macros and types defined in
-header <code>&lt;stdint.h&gt;</code>, C99 makes use of the
-symbol <code><i>N</i></code> to accommodate unusual platforms with
-word sizes that aren't powers of two. C99
-permits <code><i>N</i></code> to take on any positive integer value
-(including, for example, 24).
-
- </p>
- <p>
-
-In cstdint.syn Header <code>&lt;cstdint&gt;</code>
-synopsis, C++ on the other hand, fixes the value
-of <code><i>N</i></code> to 8, 16, 32, and 64, and specifies only
-types with these exact widths.
-
- </p>
- <p>
- </p>
-
-In addition, paragraph 1 of the same section makes use of a rather
-informal shorthand notation to specify sets of macros. When
-interpreted strictly, the notation specifies macros such
-as <code>INT_8_MIN</code> that are not intended to be specified.
-
- <p>
-
-Finally, the section is missing the usual table of symbols defined
-in that header, making it inconsistent with the rest of the
-specification.
-
- </p>
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-I propose to use the same approach in the C++ spec as C99 uses, that
-is, to specify the header synopsis in terms of "exposition only" types
-that make use of the symbol <code><i>N</i></code> to denote one or
-more of a theoretically unbounded set of widths.
-
- </p>
- <p>
-
-Further, I propose to add a new table to section listing the symbols
-defined in the header using a more formal notation that avoids
-introducing inconsistencies.
-
- </p>
- <p>
-
-To this effect, in cstdint.syn
-Header <code>&lt;cstdint&gt;</code> synopsis, replace both the
-synopsis and paragraph 1 with the following text:
-
- </p>
- <blockquote>
- <p>
- </p><ol>
- <li>
-
-In the names defined in the <code>&lt;cstdint&gt;</code> header, the
-symbol <code><i>N</i></code> represents a positive decimal integer
-with no leading zeros (e.g., 8 or 24, but not 0, 04, or 048). With the
-exception of exact-width types, macros and types for values
-of <code><i>N</i></code> in the set of 8, 16, 32, and 64 are
-required. Exact-width types, and any macros and types for values
-of <code><i>N</i></code> other than 8, 16, 32, and 64 are
-optional. However, if an implementation provides integer types with
-widths of 8, 16, 32, or 64 bits, the corresponding exact-width types
-and macros are required.
-
- </li>
- </ol>
-
- <pre>namespace std {
-
- // required types
-
- // Fastest minimum-width integer types
- typedef <i>signed integer type</i> int_fast8_t;
- typedef <i>signed integer type</i> int_fast16_t;
- typedef <i>signed integer type</i> int_fast32_t;
- typedef <i>signed integer type</i> int_fast64_t;
-
- typedef <i>unsigned integer type</i> uint_fast8_t;
- typedef <i>unsigned integer type</i> uint_fast16_t;
- typedef <i>unsigned integer type</i> uint_fast32_t;
- typedef <i>unsigned integer type</i> uint_fast64_t;
-
- // Minimum-width integer types
- typedef <i>signed integer type</i> int_least8_t;
- typedef <i>signed integer type</i> int_least16_t;
- typedef <i>signed integer type</i> int_least32_t;
- typedef <i>signed integer type</i> int_least64_t;
-
- typedef <i>unsigned integer type</i> uint_least8_t;
- typedef <i>unsigned integer type</i> uint_least16_t;
- typedef <i>unsigned integer type</i> uint_least32_t;
- typedef <i>unsigned integer type</i> uint_least64_t;
-
- // Greatest-width integer types
- typedef <i>signed integer type</i> intmax_t;
- typedef <i>unsigned integer type</i> uintmax_t;
-
- // optionally defined types
-
- // Exact-width integer types
- typedef <i>signed integer type</i> int<i>N</i>_t;
- typedef <i>unsigned integer type</i> uint<i>N</i>_t;
-
- // Fastest minimum-width integer types for values
- // of <i>N</i> other than 8, 16, 32, and 64
- typedef <i>signed integer type</i> uint_fast<i>N</i>_t;
- typedef <i>unsigned integer type</i> uint_fast<i>N</i>_t;
-
- // Minimum-width integer types for values
- // of <i>N</i> other than 8, 16, 32, and 64
- typedef <i>signed integer type</i> uint_least<i>N</i>_t;
- typedef <i>unsigned integer type</i> uint_least<i>N</i>_t;
-
- // Integer types capable of holding object pointers
- typedef <i>signed integer type</i> intptr_t;
- typedef <i>signed integer type</i> intptr_t;
-
-}</pre>
- </blockquote>
- <p>
-
-[Note to editor: Remove all of the existing paragraph 1 from cstdint.syn.]
-
- </p>
- <blockquote>
- Table ??: Header <code>&lt;cstdint&gt;</code> synopsis
- <table border="1">
- <thead>
- <tr>
- <th>Type</th>
- <th colspan="3">Name(s)</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td rowspan="11"><b>Macros:</b></td>
- <td><tt>INT<i>N</i>_MIN</tt></td>
- <td><tt>INT<i>N</i>_MAX</tt></td>
- <td><tt>UINT<i>N</i>_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>INT_FAST<i>N</i>_MIN</tt></td>
- <td><tt>INT_FAST<i>N</i>_MAX</tt></td>
- <td><tt>UINT_FAST<i>N</i>_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>INT_LEAST<i>N</i>_MIN</tt></td>
- <td><tt>INT_LEAST<i>N</i>_MAX</tt></td>
- <td><tt>UINT_LEAST<i>N</i>_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>INTPTR_MIN</tt></td>
- <td><tt>INTPTR_MAX</tt></td>
- <td><tt>UINTPTR_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>INTMAX_MIN</tt></td>
- <td><tt>INTMAX_MAX</tt></td>
- <td><tt>UINTMAX_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>PTRDIFF_MIN</tt></td>
- <td><tt>PTRDIFF_MAX</tt></td>
- <td><tt>PTRDIFF_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>SIG_ATOMIC_MIN</tt></td>
- <td><tt>SIG_ATOMIC_MAX</tt></td>
- <td><tt>SIZE_MAX</tt></td>
- </tr>
- <tr>
- <td><tt>WCHAR_MIN</tt></td>
- <td><tt>WCHAR_MAX</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>WINT_MIN</tt></td>
- <td><tt>WINT_MAX</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>INT<i>N</i>_C()</tt></td>
- <td><tt>UINT<i>N</i>_C()</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>INTMAX_C()</tt></td>
- <td><tt>UINTMAX_C()</tt></td>
- <td></td>
- </tr>
- <tr>
- <td rowspan="5"><b>Types:</b></td>
- <td><tt>int<i>N</i>_t</tt></td>
- <td><tt>uint<i>N</i>_t</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>int_fast<i>N</i>_t</tt></td>
- <td><tt>uint_fast<i>N</i>_t</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>int_least<i>N</i>_t</tt></td>
- <td><tt>uint_least<i>N</i>_t</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>intptr_t</tt></td>
- <td><tt>uintptr_t</tt></td>
- <td></td>
- </tr>
- <tr>
- <td><tt>intmax_t</tt></td>
- <td><tt>uintmax_t</tt></td>
- <td></td>
- </tr>
- </tbody>
- </table>
- </blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="842"></a>842. ConstructibleAsElement and bit containers</h3>
-<p><b>Section:</b> 23.1 [container.requirements], 23.2.7 [vector.bool], 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-23.1 [container.requirements]/p3 says:
-</p>
-
-<blockquote>
-Objects stored in these components shall be constructed using
-<tt>construct_element</tt> (20.6.9). For each operation that inserts an
-element of type <tt>T</tt> into a container (<tt>insert</tt>,
-<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
-arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
-as described in table 88. [<i>Note:</i> If the component is instantiated
-with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
-<tt>is_scoped_allocator&lt;A&gt;::value</tt> is <tt>true</tt>), then
-<tt>construct_element</tt> may pass an inner allocator argument to
-<tt>T</tt>'s constructor. <i>-- end note</i>]
-</blockquote>
-
-<p>
-However <tt>vector&lt;bool, A&gt;</tt> (23.2.7 [vector.bool]) and <tt>bitset&lt;N&gt;</tt>
-(23.3.5 [template.bitset]) store bits, not <tt>bool</tt>s, and <tt>bitset&lt;N&gt;</tt>
-does not even have an allocator. But these containers are governed by this clause. Clearly this
-is not implementable.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 23.1 [container.requirements]/p3:
-</p>
-
-<blockquote>
-Objects stored in these components shall be constructed using
-<tt>construct_element</tt> (20.6.9)<ins>, unless otherwise specified</ins>.
-For each operation that inserts an
-element of type <tt>T</tt> into a container (<tt>insert</tt>,
-<tt>push_back</tt>, <tt>push_front</tt>, <tt>emplace</tt>, etc.) with
-arguments <tt>args... T</tt> shall be <tt>ConstructibleAsElement</tt>,
-as described in table 88. [<i>Note:</i> If the component is instantiated
-with a scoped allocator of type <tt>A</tt> (i.e., an allocator for which
-<tt>is_scoped_allocator&lt;A&gt;::value</tt> is <tt>true</tt>), then
-<tt>construct_element</tt> may pass an inner allocator argument to
-<tt>T</tt>'s constructor. <i>-- end note</i>]
-</blockquote>
-
-<p>
-Change 23.2.7 [vector.bool]/p2:
-</p>
-
-<blockquote>
-Unless described below, all operations have the same requirements and semantics as the primary <tt>vector</tt> template,
-except that operations dealing with the <tt>bool</tt> value type map to bit values in the container storage<ins>,
-and <tt>construct_element</tt> (23.1 [container.requirements]) is not used to construct these values</ins>.
-</blockquote>
-
-<p>
-Move 23.3.5 [template.bitset] to clause 20.
-</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="843"></a>843. Reference Closure</h3>
-<p><b>Section:</b> 20.6.17.1 [func.referenceclosure.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-02</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The <tt>std::reference_closure</tt> type has a deleted copy assignment operator
-under the theory that references cannot be assigned, and hence the
-assignment of its reference member must necessarily be ill-formed.
-</p>
-<p>
-However, other types, notably <tt>std::reference_wrapper</tt> and <tt>std::function</tt>
-provide for the "copying of references", and thus the current definition
-of <tt>std::reference_closure</tt> seems unnecessarily restrictive. In particular,
-it should be possible to write generic functions using both <tt>std::function</tt>
-and <tt>std::reference_closure</tt>, but this generality is much harder when
-one such type does not support assignment.
-</p>
-<p>
-The definition of <tt>reference_closure</tt> does not necessarily imply direct
-implementation via reference types. Indeed, the <tt>reference_closure</tt> is
-best implemented via a frame pointer, for which there is no standard
-type.
-</p>
-<p>
-The semantics of assignment are effectively obtained by use of the
-default destructor and default copy assignment operator via
-</p>
-
-<blockquote><pre>x.~reference_closure(); new (x) reference_closure(y);
-</pre></blockquote>
-
-<p>
-So the copy assignment operator generates no significant real burden
-to the implementation.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.6.17 [func.referenceclosure] Class template reference_closure,
-replace the <tt>=delete</tt> in the copy assignment operator in the synopsis
-with <tt>=default</tt>.
-</p>
-
-<blockquote><pre>template&lt;class R , class... ArgTypes &gt;
- class reference_closure&lt;R (ArgTypes...)&gt; {
- public:
- ...
- reference_closure&amp; operator=(const reference_closure&amp;) = <del>delete</del> <ins>default</ins>;
- ...
-</pre></blockquote>
-
-<p>
-In 20.6.17.1 [func.referenceclosure.cons] Construct, copy, destroy,
-add the member function description
-</p>
-
-<blockquote>
-<pre>reference_closure&amp; operator=(const reference_closure&amp; f)
-</pre>
-<blockquote>
-<p>
-<i>Postcondition:</i> <tt>*this</tt> is a copy of <tt>f</tt>.
-</p>
-<p>
-<i>Returns:</i> <tt>*this</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="844"></a>844. <tt>complex pow</tt> return type is ambiguous</h3>
-<p><b>Section:</b> 26.3.9 [cmplx.over] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The current working draft is in an inconsistent state.
-</p>
-
-<p>
-26.3.8 [complex.transcendentals] says that:
-</p>
-
-<blockquote>
-<tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;float&gt;</tt>.
-</blockquote>
-
-<p>
-26.3.9 [cmplx.over] says that:
-</p>
-
-<blockquote>
-<tt>pow(complex&lt;float&gt;(), int())</tt> returns a <tt>complex&lt;double&gt;</tt>.
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-<p>
-Since <tt>int</tt> promotes to <tt>double</tt>, and C99 doesn't have an <tt>int</tt>-based
-overload for <tt>pow</tt>, the C99 result is <tt>complex&lt;double&gt;</tt>, see also C99
-7.22, see also library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>.
-</p>
-<p>
-Special note: ask P.J. Plauger.
-</p>
-<blockquote>
-Looks fine.
-</blockquote>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Strike this <tt>pow</tt> overload in 26.3.1 [complex.synopsis] and in 26.3.8 [complex.transcendentals]:
-</p>
-
-<blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; pow(const complex&lt;T&gt;&amp; x, int y);</del>
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="845"></a>845. atomics cannot support aggregate initialization</h3>
-<p><b>Section:</b> 29.3 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-06-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types">active issues</a> in [atomics.types].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The atomic classes (and class templates) are required to support aggregate
-initialization (29.3.1 [atomics.types.integral]p2 / 29.3.2 [atomics.types.address]p1)
-yet also have user declared constructors, so cannot be aggregates.
-</p>
-<p>
-This problem might be solved with the introduction of the proposed
-initialization syntax at Antipolis, but the wording above should be altered.
-Either strike the sentence as redundant with new syntax, or refer to 'brace
-initialization'.
-</p>
-
-<p><i>[
-Jens adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-Note that
-</p>
-<blockquote><pre>atomic_itype a1 = { 5 };
-</pre></blockquote>
-<p>
-would be aggregate-initialization syntax (now coming under the disguise
-of brace initialization), but would be ill-formed, because the corresponding
-constructor for atomic_itype is explicit. This works, though:
-</p>
-<blockquote><pre>atomic_itype a2 { 6 };
-</pre></blockquote>
-
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 29.3.1 [atomics.types.integral], strike the following sentence from paragraph 2:
-</p>
-
-<blockquote>
-The atomic integral types shall have standard layout. They shall each have a trivial default constructor, a constexpr
-explicit value constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor.
-<del>They shall each support aggregate initialization syntax.</del>
-</blockquote>
-
-<p><i>[
-2008-08-18, Lawrence adds:
-]</i></p>
-
-<blockquote>
-The syntactic compatibility of initialization with C is important.
-I suggest a different resolution; remove the explicit from the
-constructor. For the same reasons we can have implicit conversions,
-we can also have implicit constructors.
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="846"></a>846. No definition for constructor</h3>
-<p><b>Section:</b> 29.3 [atomics.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-06-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#atomics.types">active issues</a> in [atomics.types].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types">issues</a> in [atomics.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The atomic classes and class templates (29.3.1 [atomics.types.integral] /
-29.3.2 [atomics.types.address]) have a constexpr
-constructor taking a value of the appropriate type for that atomic.
-However, neither clause provides semantics or a definition for this
-constructor. I'm not sure if the initialization is implied by use of
-constexpr keyword (which restricts the form of a constructor) but even if
-that is the case, I think it is worth spelling out explicitly as the
-inference would be far too subtle in that case.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="847"></a>847. string exception safety guarantees</h3>
-<p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Herv Brnnimann <b>Date:</b> 2008-06-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In March, on comp.lang.c++.moderated, I asked what were the
-string exception safety guarantees are, because I cannot see
-*any* in the working paper, and any implementation I know offers
-the strong exception safety guarantee (string unchanged if a
-member throws exception). The closest the current draft comes to
-offering any guarantees is 21.3 [basic.string], para 3:
-</p>
-
-<blockquote>
-The class template <tt>basic_string</tt> conforms to the requirements
-for a Sequence Container (23.1.1), for a Reversible Container (23.1),
-and for an Allocator-aware container (91). The iterators supported by
-<tt>basic_string</tt> are random access iterators (24.1.5).
-</blockquote>
-
-<p>
-However, the chapter 23 only says, on the topic of exceptions: 23.1 [container.requirements],
-para 10:
-</p>
-
-<blockquote>
-<p>
-Unless otherwise specified (see 23.2.2.3 and 23.2.6.4) all container types defined in this clause meet the following
-additional requirements:
-</p>
-
-<ul>
-<li>if an exception is thrown by...</li>
-</ul>
-</blockquote>
-
-<p>
-I take it as saying that this paragraph has *no* implication on
-<tt>std::basic_string</tt>, as <tt>basic_string</tt> isn't defined in Clause 23 and
-this paragraph does not define a *requirement* of Sequence
-nor Reversible Container, just of the models defined in Clause 23.
-In addition, LWG Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a> proposes to remove 23.1 [container.requirements], para 3.
-</p>
-
-<p>
-Finally, the fact that no operation on Traits should throw
-exceptions has no bearing, except to suggest (since the only
-other throws should be allocation, <tt>out_of_range</tt>, or <tt>length_error</tt>)
-that the strong exception guarantee can be achieved.
-</p>
-
-<p>
-The reaction in that group by Niels Dekker, Martin Sebor, and
-Bo Persson, was all that this would be worth an LWG issue.
-</p>
-
-<p>
-A related issue is that <tt>erase()</tt> does not throw. This should be
-stated somewhere (and again, I don't think that the 23.1 [container.requirements], para 1
-applies here).
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a blanket statement in 21.3.1 [string.require]:
-</p>
-
-<blockquote>
-<p>
-- if any member function or operator of <tt>basic_string&lt;charT, traits, Allocator&gt;</tt>
-throws, that function or operator has no effect.
-</p>
-<p>
-- no <tt>erase()</tt> or <tt>pop_back()</tt> function throws.
-</p>
-</blockquote>
-
-<p>
-As far as I can tell, this is achieved by any implementation. If I made a
-mistake and it is not possible to offer this guarantee, then
-either state all the functions for which this is possible
-(certainly at least <tt>operator+=</tt>, <tt>append</tt>, <tt>assign</tt>, and <tt>insert</tt>),
-or add paragraphs to Effects clauses wherever appropriate.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="848"></a>848. missing <tt>std::hash</tt> specializations for <tt>std::bitset/std::vector&lt;bool&gt;</tt></h3>
-<p><b>Section:</b> 20.6.16 [unord.hash] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-06-05</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In the current working draft, <tt>std::hash&lt;T&gt;</tt> is specialized for builtin
-types and a few other types. Bitsets seems like one that is missing from
-the list, not because it cannot not be done by the user, but because it
-is hard or impossible to write an efficient implementation that works on
-32bit/64bit chunks at a time. For example, <tt>std::bitset</tt> is too much
-encapsulated in this respect.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following to the synopsis in 20.6 [function.objects]/2:
-</p>
-
-<blockquote><pre>template&lt;class Allocator&gt; struct hash&lt;std::vector&lt;bool,Allocator&gt;&gt;;
-template&lt;size_t N&gt; struct hash&lt;std::bitset&lt;N&gt;&gt;;
-</pre></blockquote>
-
-<p>
-Modify the last sentence of 20.6.16 [unord.hash]/1 to end with:
-</p>
-
-<blockquote>
-... and <tt>std::string</tt>, <tt>std::u16string</tt>, <tt>std::u32string</tt>, <tt>std::wstring</tt>,
-<tt>std::error_code</tt>, <tt>std::thread::id</tt>, <tt>std::bitset</tt>, <tt>and std::vector&lt;bool&gt;</tt>.
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="849"></a>849. missing type traits to compute root class and derived class of types in a class hierachy</h3>
-<p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-06-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The type traits library contains various traits to dealt with
-polymorphic types, e.g. <tt>std::has_virtual_destructor</tt>, <tt>std::is_polymorphic</tt>
-and <tt>std::is_base_of</tt>. However, there is no way to compute the unique
-public base class of a type if such one exists. Such a trait could be
-very useful if one needs to instantiate a specialization made for the
-root class whenever a derived class is passed as parameter. For example,
-imagine that you wanted to specialize <tt>std::hash</tt> for a class
-hierarchy---instead of specializing each class, you could specialize the
-<tt>std::hash&lt;root_class&gt;</tt> and provide a partial specialization that worked
-for all derived classes.
-</p>
-
-<p>
-This ability---to specify operations in terms of their equivalent in the
-root class---can be done with e.g. normal functions, but there is,
-AFAIK, no way to do it for class templates. Being able to access
-compile-time information about the type-hierachy can be very powerful,
-and I therefore also suggest traits that computes the directly derived
-class whenever that is possible.
-</p>
-
-<p>
-If the computation can not be done, the traits should fall back on an
-identity transformation. I expect this gives the best overall usability.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following to the synopsis in 20.5.2 [meta.type.synop] under "other transformations":
-</p>
-
-<blockquote><pre>template&lt; class T &gt; struct direct_base_class;
-template&lt; class T &gt; struct direct_derived_class;
-template&lt; class T &gt; struct root_base_class;
-</pre></blockquote>
-
-<p>
-Add three new entries to table 51 (20.5.7 [meta.trans.other]) with the following content
-</p>
-
-<blockquote>
-<table border="1">
-<tbody><tr>
-<th>Template</th><th>Condition</th><th>Comments</th>
-</tr>
-<tr>
-<td><tt>template&lt; class T &gt; struct direct_base_class;</tt></td>
-<td><tt>T</tt> shall be a complete type.</td>
-<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous direct base class of <tt>T</tt>.
-If no such type exists, the member typedef <tt>type</tt> shall equal <tt>T</tt>.</td>
-</tr>
-<tr>
-<td><tt>template&lt; class T &gt; struct direct_derived_class;</tt></td>
-<td><tt>T</tt> shall be a complete type.</td>
-<td>The member typedef <tt>type</tt> shall equal the unambiguous type which has <tt>T</tt>
-as an accessible unambiguous direct base class. If no such type exists, the member typedef
-<tt>type</tt> shall equal <tt>T</tt>.</td>
-</tr>
-<tr>
-<td><tt>template&lt; class T &gt; struct root_base_class;</tt></td>
-<td><tt>T</tt> shall be a complete type.</td>
-<td>The member typedef <tt>type</tt> shall equal the accessible unambiguous most indirect base class of
-<tt>T</tt>. If no such type exists, the member typedef type shall equal <tt>T</tt>.</td>
-</tr>
-</tbody></table>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="850"></a>850. Should <tt>shrink_to_fit</tt> apply to <tt>std::deque</tt>?</h3>
-<p><b>Section:</b> 23.2.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Niels Dekker <b>Date:</b> 2008-06-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#deque.capacity">active issues</a> in [deque.capacity].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a> added a <tt>shrink_to_fit</tt> function to <tt>std::vector</tt> and <tt>std::string</tt>.
-It did not yet deal with <tt>std::deque</tt>, because of the fundamental
-difference between <tt>std::deque</tt> and the other two container types. The
-need for <tt>std::deque</tt> may seem less evident, because one might think that
-for this container, the overhead is a small map, and some number of
-blocks that's bounded by a small constant.
-</p>
-<p>
-The container overhead can in fact be arbitrarily large (i.e. is not
-necessarily O(N) where N is the number of elements currently held by the
-<tt>deque</tt>). As Bill Plauger noted in a reflector message, unless the map of
-block pointers is shrunk, it must hold at least maxN/B pointers where
-maxN is the maximum of N over the lifetime of the <tt>deque</tt> since its
-creation. This is independent of how the map is implemented
-(<tt>vector</tt>-like circular buffer and all), and maxN bears no relation to N,
-the number of elements it currently holds.
-</p>
-<p>
-Herv Brnnimann reports a situation where a <tt>deque</tt> of requests grew very
-large due to some temporary backup (the front request hanging), and the
-map of the <tt>deque</tt> grew quite large before getting back to normal. Just
-to put some color on it, assuming a <tt>deque</tt> with 1K pointer elements in
-steady regime, that held, at some point in its lifetime, maxN=10M
-pointers, with one block holding 128 elements, the spine must be at
-least (maxN / 128), in that case 100K. In that case, shrink-to-fit
-would allow to reuse about 100K which would otherwise never be reclaimed
-in the lifetime of the <tt>deque</tt>.
-</p>
-<p>
-An added bonus would be that it *allows* implementations to hang on to
-empty blocks at the end (but does not care if they do or not). A
-<tt>shrink_to_fit</tt> would take care of both shrinks, and guarantee that at
-most O(B) space is used in addition to the storage to hold the N
-elements and the N/B block pointers.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-To Class template deque 23.2.2 [deque] synopsis, add:
-</p>
-<blockquote><pre>void shrink_to_fit();
-</pre></blockquote>
-
-<p>
-To deque capacity 23.2.2.2 [deque.capacity], add:
-</p>
-<blockquote><pre>void shrink_to_fit();
-</pre>
-
-<blockquote>
-<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce memory
-use. [<i>Note:</i> The request is non-binding to allow latitude for
-implementation-specific optimizations. -- <i>end note</i>]
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="851"></a>851. simplified array construction</h3>
-<p><b>Section:</b> 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>
- <b>Submitter:</b> Benjamin Kosnik <b>Date:</b> 2008-06-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Review">Review</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-This is an issue that came up on the libstdc++ list, where a
-discrepency between "C" arrays and C++0x's <tt>std::array</tt> was pointed
-out.
-</p>
-
-<p>
-In "C," this array usage is possible:
-</p>
-
-<blockquote><pre>int ar[] = {1, 4, 6};
-</pre></blockquote>
-
-<p>
-But for C++,
-</p>
-
-<blockquote><pre>std::array&lt;int&gt; a = { 1, 4, 6 }; // error
-</pre></blockquote>
-
-<p>
-Instead, the second parameter of the <tt>array</tt> template must be
-explicit, like so:
-</p>
-
-<blockquote><pre>std::array&lt;int, 3&gt; a = { 1, 4, 6 };
-</pre></blockquote>
-
-<p>
-Doug Gregor proposes the following solution, that assumes
-generalized initializer lists.
-</p>
-
-<blockquote><pre>template&lt;typename T, typename... Args&gt;
-inline array&lt;T, sizeof...(Args)&gt;
-make_array(Args&amp;&amp;... args)
-{ return { std::forward&lt;Args&gt;(args)... }; }
-</pre></blockquote>
-
-<p>
-Then, the way to build an <tt>array</tt> from a list of unknown size is:
-</p>
-
-<blockquote><pre>auto a = make_array&lt;T&gt;(1, 4, 6);
-</pre></blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to the <tt>array</tt> synopis in 23.2 [sequences]:
-</p>
-
-<blockquote><pre>template&lt;typename T, typename... Args&gt;
- requires Convertible&lt;Args, T&gt;...
- array&lt;T, sizeof...(Args)&gt;
- make_array(Args&amp;&amp;... args);
-</pre></blockquote>
-
-<p>
-Append after 23.2.1.6 [array.tuple] Tuple interface to class template <tt>array</tt> the
-following new section.
-</p>
-
-<blockquote>
-<p>
-23.2.1.7 Convenience interface to class template <tt>array</tt> [array.tuple]
-</p>
-
-<pre>template&lt;typename T, typename... Args&gt;
- requires Convertible&lt;Args, T&gt;...
- array&lt;T, sizeof...(Args)&gt;
- make_array(Args&amp;&amp;... args);
-</pre>
-
-<blockquote>
-<p>
-<i>Returns:</i> <tt>{std::forward&lt;Args&gt;(args)...}</tt>
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="852"></a>852. unordered containers <tt>begin(n)</tt> mistakenly <tt>const</tt></h3>
-<p><b>Section:</b> 23.4 [unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>
- <b>Submitter:</b> Robert Klarer <b>Date:</b> 2008-06-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Ready">Ready</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 3 of the four unordered containers the local <tt>begin</tt> member is mistakenly declared <tt>const</tt>:
-</p>
-
-<blockquote><pre>local_iterator begin(size_type n) const;
-</pre></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 23.4.1 [unord.map], 23.4.2 [unord.multimap], and 23.4.4 [unord.multiset]:
-</p>
-
-<blockquote><pre>local_iterator begin(size_type n)<del> const</del>;
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="853"></a>853. <tt>to_string</tt> needs updating with <tt>zero</tt> and <tt>one</tt></h3>
-<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a> adds defaulted arguments to the <tt>to_string</tt> member, but neglects to update
-the three newer <tt>to_string</tt> overloads.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 23.3.5 [template.bitset], and the signatures in 23.3.5.2 [bitset.members] to:
-</p>
-
-<blockquote><pre>template &lt;class charT, class traits&gt;
- basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt; to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
-template &lt;class charT&gt;
- basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt; to_string(<ins>charT zero = charT('0'), charT one = charT('1')</ins>) const;
-basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt; to_string(<ins>char zero = '0', char one = '1'</ins>) const;
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="854"></a>854. <tt>default_delete</tt> converting constructor underspecified</h3>
-<p><b>Section:</b> 20.7.11.1.1 [unique.ptr.dltr.dflt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2008-06-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-No relationship between <tt>U</tt> and <tt>T</tt> in the converting constructor for <tt>default_delete</tt> template.
-</p>
-<p>
-Requirements: <tt>U*</tt> is convertible to <tt>T*</tt> and <tt>has_virtual_destructor&lt;T&gt;</tt>;
-the latter should also become a concept.
-</p>
-<p>
-Rules out cross-casting.
-</p>
-<p>
-The requirements for <tt>unique_ptr</tt> conversions should be the same as those on the deleter.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.7.11.1.1 [unique.ptr.dltr.dflt]:
-</p>
-
-<blockquote><pre>namespace std {
- template &lt;class T&gt; struct default_delete {
- default_delete();
- template &lt;class U&gt;
- <ins>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</ins>
- default_delete(const default_delete&lt;U&gt;&amp;);
- void operator()(T*) const;
- };
-}
-</pre></blockquote>
-
-<p>
-...
-</p>
-
-<blockquote><pre>template &lt;class U&gt;
- <ins>requires Convertible&lt;U*, T*&gt; &amp;&amp; HasVirtualDestructor&lt;T&gt;</ins>
- default_delete(const default_delete&lt;U&gt;&amp; other);
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="855"></a>855. capacity() and reserve() for deque?</h3>
-<p><b>Section:</b> 23.2.2.2 [deque.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Herv Brnnimann <b>Date:</b> 2008-06-11</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#deque.capacity">active issues</a> in [deque.capacity].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.capacity">issues</a> in [deque.capacity].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The main point is that <tt>capacity</tt> can be viewed as a mechanism to
-guarantee the validity of <tt>iterators</tt> when only <tt>push_back/pop_back</tt>
-operations are used. For <tt>vector</tt>, this goes with reallocation. For
-<tt>deque</tt>, this is a bit more subtle: <tt>capacity()</tt> of a <tt>deque</tt> may shrink,
-whereas that of <tt>vector</tt> doesn't. In a circular buffer impl. of the
-map, as Howard did, there is very similar notion of capacity: as long
-as <tt>size()</tt> is less than <tt>B * (</tt>total size of the map <tt>- 2)</tt>, it is
-guaranteed that no <tt>iterator</tt> is invalidated after any number of
-<tt>push_front/back</tt> and <tt>pop_front/back</tt> operations. But this does not
-hold for other implementations.
-</p>
-<p>
-Still, I believe, <tt>capacity()</tt> can be defined by <tt>size() +</tt> how many
-<tt>push_front/back</tt> minus <tt>pop_front/back</tt> that can be performed before
-terators are invalidated. In a classical impl., <tt>capacity() = size()
-+ </tt> the min distance to either "physical" end of the deque (i.e.,
-counting the empty space in the last block plus all the blocks until
-the end of the map of block pointers). In Howard's circular buffer
-impl., <tt>capacity() = B * (</tt>total size of the map <tt>- 2)</tt> still works with
-this definition, even though the guarantee could be made stronger.
-</p>
-<p>
-A simple picture of a deque:
-</p>
-<blockquote><pre>A-----|----|-----|---F+|++++|++B--|-----|-----Z
-</pre></blockquote>
-<p>
-(A,Z mark the beginning/end, | the block boundaries, F=front, B=back,
-and - are uninitialized, + are initialized)
-In that picture: <tt>capacity = size() + min(dist(A,F),dist(B,Z)) = min
-(dist(A,B),dist(F,Z))</tt>.
-</p>
-<p>
-<tt>Reserve(n)</tt> can grow the map of pointers and add possibly a number of
-empty blocks to it, in order to guarantee that the next <tt>n-size()
-push_back/push_front</tt> operations will not invalidate iterators, and
-also will not allocate (i.e. cannot throw). The second guarantee is
-not essential and can be left as a QoI. I know well enough existing
-implementations of <tt>deque</tt> (sgi/stl, roguewave, stlport, and
-dinkumware) to know that either can be implemented with no change to
-the existing class layout and code, and only a few modifications if
-blocks are pre-allocated (instead of always allocating a new block,
-check if the next entry in the map of block pointers is not zero).
-</p>
-<p>
-Due to the difference with <tt>vector</tt>, wording is crucial. Here's a
-proposed wording to make things concrete; I tried to be reasonably
-careful but please double-check me:
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Add new signatures to synopsis in 23.2.2 [deque]:
-</p>
-
-<blockquote><pre>size_type capacity() const;
-bool reserve(size_type n);
-</pre></blockquote>
-
-<p>
-Add new signatures to 23.2.2.2 [deque.capacity]:
-</p>
-
-<blockquote>
-<pre>size_type capacity() const;
-</pre>
-<blockquote>
-<p>
-1 <i>Returns:</i> An upper bound on <tt>n + max(n_f - m_f, n_b - m_b)</tt> such
-that, for any sequence of <tt>n_f push_front</tt>, <tt>m_f pop_front</tt>, <tt>n_b
-push_back</tt>, and <tt>m_b pop_back</tt> operations, interleaved in any order,
-starting with the current <tt>deque</tt> of size <tt>n</tt>, the <tt>deque</tt> does not
-invalidate any of its iterators except to the erased elements.
-</p>
-<p>
-2 <i>Remarks:</i> Unlike a <tt>vector</tt>'s capacity, the capacity of a <tt>deque</tt> can
-decrease after a sequence of insertions at both ends, even if none of
-the operations caused the <tt>deque</tt> to invalidate any of its iterators
-except to the erased elements.
-</p>
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>bool reserve(size_type n);
-</pre>
-<blockquote>
-<p>
-2 <i>Effects:</i> A directive that informs a <tt>deque</tt> of a planned sequence of
-<tt>push_front</tt>, <tt>pop_front</tt>, <tt>push_back</tt>, and <tt>pop_back</tt> operations, so that it
-can manage iterator invalidation accordingly. After <tt>reserve()</tt>,
-<tt>capacity()</tt> is greater or equal to the argument of <tt>reserve</tt> if this
-operation returns <tt>true</tt>; and equal to the previous value of <tt>capacity()</tt>
-otherwise. If an exception is thrown, there are no effects.
-</p>
-<p>
-3 <i>Returns:</i> <tt>true</tt> if iterators are invalidated as a result of this
-operation, and false otherwise.
-</p>
-<p>
-4 <i>Complexity:</i> It does not change the size of the sequence and takes
-at most linear time in <tt>n</tt>.
-</p>
-<p>
-5 <i>Throws:</i> <tt>length_error</tt> if <tt>n &gt; max_size()</tt>.
-</p>
-<p>
-6 <i>Remarks:</i> It is guaranteed that no invalidation takes place during a
-sequence of <tt>insert</tt> or <tt>erase</tt> operations at either end that happens
-after a call to <tt>reserve()</tt> except to the erased elements, until the
-time when an insertion would make <tt>max(n_f-m_f, n_b-m_b)</tt> larger than
-<tt>capacity()</tt>, where <tt>n_f</tt> is the number of <tt>push_front</tt>, <tt>m_f</tt> of <tt>pop_front</tt>,
-<tt>n_b</tt> of <tt>push_back</tt>, and <tt>m_b</tt> of <tt>pop_back</tt> operations since the call to
-<tt>reserve()</tt>.
-</p>
-<p>
-7 An implementation is free to pre-allocate buffers so as to
-offer the additional guarantee that no exception will be thrown
-during such a sequence other than by the element constructors.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-And 23.2.2.3 [deque.modifiers] para 1, can be enhanced:
-</p>
-
-<blockquote>
-1 <i>Effects:</i> An insertion in the middle of the deque invalidates all the iterators and references to elements of the
-deque. An insertion at either end of the deque invalidates all the iterators to the deque,
-<ins>unless provisions have been made with reserve,</ins>
-but has no effect on the validity of references to elements of the deque.
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="856"></a>856. Removal of <tt>aligned_union</tt></h3>
-<p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2008-06-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-With the arrival of extended unions
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf">N2544</a>),
-there is no
-known use of <tt>aligned_union</tt> that couldn't be handled by
-the "extended unions" core-language facility.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove the following signature from 20.5.2 [meta.type.synop]:
-</p>
-<blockquote><pre>template &lt;std::size_t Len, class... Types&gt; struct aligned_union;
-</pre></blockquote>
-
-<p>
-Remove the second row from table 51 in 20.5.7 [meta.trans.other],
-starting with:
-</p>
-
-<blockquote><pre>template &lt;std::size_t Len,
-class... Types&gt;
-struct aligned_union;
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="857"></a>857. <tt>condition_variable::time_wait</tt> return <tt>bool</tt> error prone</h3>
-<p><b>Section:</b> 30.4.1 [thread.condition.condvar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2008-06-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The meaning of the <tt>bool</tt> returned by <tt>condition_variable::timed_wait</tt> is so
-obscure that even the class' designer can't deduce it correctly. Several
-people have independently stumbled on this issue.
-</p>
-<p>
-It might be simpler to change the return type to a scoped enum:
-</p>
-<blockquote><pre>enum class timeout { not_reached, reached };
-</pre></blockquote>
-
-<p>
-That's the same cost as returning a <tt>bool</tt>, but not subject to mistakes. Your example below would be:
-</p>
-
-<blockquote><pre>if (cv.wait_until(lk, time_limit) == timeout::reached )
- throw time_out();
-</pre></blockquote>
-
-<p><i>[
-Beman to supply exact wording.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="858"></a>858. Wording for Minimal Support for Garbage Collection</h3>
-<p><b>Section:</b> X [garbage.collection] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2008-06-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The first sentence of the Effects clause for <tt>undeclare_reachable</tt> seems
-to be missing some words. I can't parse
-</p>
-<blockquote>
-... for all non-null <tt>p</tt> referencing the argument is no longer declared reachable...
-</blockquote>
-<p>
-I take it the intent is that <tt>undeclare_reachable</tt> should be called only
-when there has been a corresponding call to <tt>declare_reachable</tt>. In
-particular, although the wording seems to allow it, I assume that code
-shouldn't call <tt>declare_reachable</tt> once then call <tt>undeclare_reachable</tt>
-twice.
-</p>
-<p>
-I don't know what "shall be live" in the Requires clause means.
-</p>
-<p>
-In the final Note for <tt>undeclare_reachable</tt>, what does "cannot be
-deallocated" mean? Is this different from "will not be able to collect"?
-</p>
-
-<p>
-For the wording on nesting of <tt>declare_reachable</tt> and
-<tt>undeclare_reachable</tt>, the words for locking and unlocking recursive
-mutexes probably are a good model.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="859"></a>859. Monotonic Clock is Conditionally Supported?</h3>
-<p><b>Section:</b> X [datetime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2008-06-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661</a>
-says that there is a class named <tt>monotonic_clock</tt>. It also says that this
-name may be a synonym for <tt>system_clock</tt>, and that it's conditionally
-supported. So the actual requirement is that it can be monotonic or not,
-and you can tell by looking at <tt>is_monotonic</tt>, or it might not exist at
-all (since it's conditionally supported). Okay, maybe too much
-flexibility, but so be it.
-</p>
-<p>
-A problem comes up in the threading specification, where several
-variants of <tt>wait_for</tt> explicitly use <tt>monotonic_clock::now()</tt>. What is the
-meaning of an effects clause that says
-</p>
-
-<blockquote><pre>wait_until(lock, chrono::monotonic_clock::now() + rel_time)
-</pre></blockquote>
-
-<p>
-when <tt>monotonic_clock</tt> is not required to exist?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="860"></a>860. Floating-Point State</h3>
-<p><b>Section:</b> 26 [numerics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-06-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There are a number of functions that affect the floating point state.
-These function need to be thread-safe, but I'm unsure of the right
-approach in the standard, as we inherit them from C.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="861"></a>861. Incomplete specification of EqualityComparable for std::forward_list</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-06-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Table 89, Container requirements, defines <tt>operator==</tt> in terms of the container
-member function <tt>size()</tt> and the algorithm <tt>std::equal</tt>:
-</p>
-
-<blockquote>
-<tt>==</tt> is an equivalence relation. <tt>a.size() == b.size() &amp;&amp;
-equal(a.begin(), a.end(), b.begin()</tt>
-</blockquote>
-
-<p>
-The new container <tt>forward_list</tt> does not provide a <tt>size</tt> member function
-by design but does provide <tt>operator==</tt> and <tt>operator!=</tt> without specifying it's semantic.
-</p>
-<p>
-Other parts of the (sequence) container requirements do also depend on
-<tt>size()</tt>, e.g. <tt>empty()</tt>
-or <tt>clear()</tt>, but this issue explicitly attempts to solve the missing
-<tt>EqualityComparable</tt> specification,
-because of the special design choices of <tt>forward_list</tt>.
-</p>
-<p>
-I propose to apply one of the following resolutions, which are described as:
-</p>
-
-<ol type="A">
-<li>
-Provide a definition, which is optimal for this special container without
-previous size test. This choice prevents two <tt>O(N)</tt> calls of <tt>std::distance()</tt>
-with the corresponding container ranges and instead uses a special
-<tt>equals</tt> implementation which takes two container ranges instead of 1 1/2.
-</li>
-<li>
-The simple fix where the usual test is adapted such that <tt>size()</tt> is replaced
-by <tt>distance</tt> with corresponding performance disadvantages.
-</li>
-</ol>
-<p>
-Both proposal choices are discussed, the preferred choice of the author is
-to apply (A).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Common part:
-</p>
-<ul>
-<li>
-<p>
-Just betwen 23.2.3.5 [forwardlist.ops] and 23.2.3.6 [forwardlist.spec]
-add a new
-section "forwardlist comparison operators" [forwardlist.compare] (and
-also add the
-new section number to 23.2.3 [forwardlist]/2 in front of "Comparison operators"):
-</p>
-<blockquote>
-forwardlist comparison operators [forwardlist.compare]
-</blockquote>
-</li>
-</ul>
-
-<p>
-Option (A):
-</p>
-<blockquote>
-<ul>
-<li>
-<p>
-Add to the new section [forwardlist.compare] the following paragraphs:
-</p>
-
-<blockquote>
-<pre>template &lt;class T, class Allocator&gt;
-bool operator==(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; y);
-</pre>
-<blockquote>
-<p>
-<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
-</p>
-<p>
-<i>Returns:</i> <tt>true</tt> if
-</p>
-<ul>
-<li>
-<p>
-for every iterator <tt>i</tt> in the range <tt>[x.begin(), E)</tt>, where <tt>E ==
-x.begin() + M</tt> and <tt>M ==
- min(distance(x.begin(), x.end()), distance(y.begin(), y.end()))</tt>,
-the following condition holds:
-</p>
-<blockquote><pre>*i == *(y.begin() + (i - x.begin())).
-</pre></blockquote>
-</li>
-<li>
-if <tt>i == E</tt> then <tt>i == x.end() &amp;&amp; (y.begin() + (i - x.begin())) == y.end()</tt>.
-</li>
-<li>
-Otherwise, returns <tt>false</tt>.
-</li>
-</ul>
-<p>
-<i>Throws:</i> Nothing unless an exception is thrown by the equality comparison.
-</p>
-<p>
-<i>Complexity:</i> At most <tt>M</tt> comparisons.
-</p>
-</blockquote>
-<pre>template &lt;class T, class Allocator&gt;
-bool operator!=(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; y);
-</pre>
-<blockquote>
-<i>Returns:</i> <tt>!(x == y)</tt>.
-</blockquote>
-</blockquote>
-</li>
-</ul>
-</blockquote>
-
-<p>
-Option (B):
-</p>
-<blockquote>
-<ul>
-<li>
-<p>
-Add to the new section [forwardlist.compare] the following paragraphs:
-</p>
-<blockquote>
-<pre>template &lt;class T, class Allocator&gt;
-bool operator==(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; y);
-</pre>
-<blockquote>
-<p>
-<i>Requires:</i> Type <tt>T</tt> is <tt>EqualityComparable</tt> ([equalitycomparable]).
-</p>
-<p>
-<i>Returns:</i> <tt>distance(x.begin(), x.end()) == distance(y.begin(), y.end())
-&amp;&amp; equal(x.begin(), x.end(), y.begin())</tt>.
-</p>
-</blockquote>
-<pre>template &lt;class T, class Allocator&gt;
-bool operator!=(const forward_list&lt;T,Allocator&gt;&amp; x, const forward_list&lt;T,Allocator&gt;&amp; y);
-</pre>
-<blockquote>
-<i>Returns:</i> <tt>!(x == y)</tt>.
-</blockquote>
-</blockquote>
-</li>
-</ul>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="862"></a>862. Impossible complexity for 'includes'</h3>
-<p><b>Section:</b> 25.3.5.1 [includes] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-07-02</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 25.3.5.1 [includes] the complexity is "at most -1 comparisons" if passed
-two empty ranges. I don't know how to perform a negative number of
-comparisions!
-</p>
-
-<p>
-This same issue also applies to:
-</p>
-
-<ul>
-<li><tt>set_union</tt></li>
-<li><tt>set_intersection</tt></li>
-<li><tt>set_difference</tt></li>
-<li><tt>set_symmetric_difference</tt></li>
-<li><tt>merge</tt></li>
-</ul>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="863"></a>863. What is the state of a stream after close() succeeds</h3>
-<p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 2008-07-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Suppose writing to an <tt>[o]fstream</tt> fails and you later close the <tt>stream</tt>.
-The <tt>overflow()</tt> function is called to flush the buffer (if it exists).
-Then the file is unconditionally closed, as if by calling <tt>flcose</tt>.
-</p>
-<p>
-If either <tt>overflow</tt> or <tt>fclose</tt> fails, <tt>close()</tt> reports failure, and clearly
-the <tt>stream</tt> should be in a failed or bad state.
-</p>
-<p>
-Suppose the buffer is empty or non-existent (so that <tt>overflow()</tt> does not
-fail), and <tt>fclose</tt> succeeds. The <tt>close()</tt> function reports success, but
-what is the state of the <tt>stream</tt>?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="864"></a>864. Defect in atomic wording</h3>
-<p><b>Section:</b> 29.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Anthony Williams <b>Date:</b> 2008-07-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There's an error in 29.4 [atomics.types.operations]/p9:
-</p>
-
-<blockquote>
-<pre>C atomic_load(const volatile A * object);
-C atomic_load_explicit(const volatile A * object, memory_order);
-C A ::load(memory_order order = memory_order_seq_cst) const volatile;
-</pre>
-<blockquote>
-<p>
-<i>Requires:</i> The <tt>order</tt> argument shall not be <tt>memory_order_acquire</tt> nor
-<tt>memory_order_acq_rel</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-I believe that this should state
-</p>
-<blockquote>
-shall not be <tt>memory_order_release</tt>.
-</blockquote>
-
-<p>
-There's also an error in 29.4 [atomics.types.operations]/p17:
-</p>
-
-<blockquote>
-... When only one <tt>memory_order</tt> argument is supplied, the value of success
-is <tt>order</tt>, and
-the value of failure is <tt>order</tt> except that a value of
-<tt>memory_order_acq_rel</tt> shall be replaced by the value
-<tt>memory_order_require</tt> ...
-</blockquote>
-<p>
-I believe this should state
-</p>
-<blockquote>
-shall be replaced by the value <tt>memory_order_acquire</tt> ...
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 29.4 [atomics.types.operations]/p9:
-</p>
-
-<blockquote>
-<pre>C atomic_load(const volatile A * object);
-C atomic_load_explicit(const volatile A * object, memory_order);
-C A ::load(memory_order order = memory_order_seq_cst) const volatile;
-</pre>
-<blockquote>
-<p>
-<i>Requires:</i> The <tt>order</tt> argument shall not be <del><tt>memory_order_acquire</tt></del>
-<ins><tt>memory_order_release</tt></ins> nor <tt>memory_order_acq_rel</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-Change 29.4 [atomics.types.operations]/p17:
-</p>
-
-<blockquote>
-... When only one <tt>memory_order</tt> argument is supplied, the value of success
-is <tt>order</tt>, and
-the value of failure is <tt>order</tt> except that a value of
-<tt>memory_order_acq_rel</tt> shall be replaced by the value
-<del><tt>memory_order_require</tt></del> <ins><tt>memory_order_acquire</tt></ins> ...
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="865"></a>865. More algorithms that throw away information</h3>
-<p><b>Section:</b> 25.2.6 [alg.fill], 25.2.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-07-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In regard to library defect <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a> I found some more algorithms which
-unnecessarily throw away information. These are typically algorithms,
-which sequentially write into an <tt>OutputIterator</tt>, but do not return the
-final value of this output iterator. These cases are:
-</p>
-
-<ol>
-<li>
-<pre>template&lt;class OutputIterator, class Size, class T&gt;
-void fill_n(OutputIterator first, Size n, const T&amp; value);</pre></li>
-
-<li>
-<pre>template&lt;class OutputIterator, class Size, class Generator&gt;
-void generate_n(OutputIterator first, Size n, Generator gen);</pre></li>
-</ol>
-<p>
-In both cases the minimum requirements on the iterator are
-<tt>OutputIterator</tt>, which means according to the requirements of
-24.1.2 [output.iterators]/2 that only single-pass iterations are guaranteed.
-So, if users of <tt>fill_n</tt> and <tt>generate_n</tt> have *only* an <tt>OutputIterator</tt>
-available, they have no chance to continue pushing further values
-into it, which seems to be a severe limitation to me.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>
-Replace the current declaration of <tt>fill_n</tt> in 25 [algorithms]/2, header
-<tt>&lt;algorithm&gt;</tt> synopsis and in 25.2.6 [alg.fill] by
-</p>
-
-<blockquote><pre>template&lt;class OutputIterator, class Size, class T&gt;
-<del>void</del> <ins>OutputIterator</ins> fill_n(OutputIterator first, Size n, const T&amp; value);
-</pre></blockquote>
-<p>
-Just after the effects clause p.2 add a new returns clause saying:
-</p>
-<blockquote>
-<i>Returns:</i> <tt>first + n</tt> for <tt>fill_n</tt>.
-</blockquote>
-</li>
-<li>
-<p>
-Replace the current declaration of <tt>generate_n</tt> in 25 [algorithms]/2, header
-<tt>&lt;algorithm&gt;</tt> synopsis and in 25.2.7 [alg.generate] by
-</p>
-<blockquote><pre>template&lt;class OutputIterator, class Size, class Generator&gt;
-<del>void</del> <ins>OutputIterator</ins> generate_n(OutputIterator first, Size n, Generator gen);
-</pre></blockquote>
-<p>
-Just after the effects clause p.1 add a new returns clause saying:
-</p>
-<blockquote>
-<i>Returns:</i> <tt>first + n</tt> for <tt>generate_n</tt>.
-</blockquote>
-</li>
-</ol>
-
-
-
-
-
-<hr>
-<h3><a name="866"></a>866. Qualification of placement new-expressions</h3>
-<p><b>Section:</b> 20.7.10 [specialized.algorithms], 20.7.12.2.6 [util.smartptr.shared.create] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> replaced "<tt>new</tt>" with "<tt>::new</tt>" in the placement
-new-expression in 20.7.5.1 [allocator.members]. I believe the rationale
-given in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a> applies also to the following other contexts:
-</p>
-<ul>
-<li>
-<p>
-in 20.7.10 [specialized.algorithms], all four algorithms <tt>unitialized_copy</tt>,
-<tt>unitialized_copy_n</tt>, <tt>unitialized_fill</tt> and <tt>unitialized_fill_n</tt> use
-the unqualified placement new-expression in some variation of the form:
-</p>
-<blockquote><pre>new (static_cast&lt;void*&gt;(&amp;*result)) typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
-</pre></blockquote>
-</li>
-<li>
-<p>
-in 20.7.12.2.6 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
-</p>
-<blockquote><pre>new (pv) T(std::forward&lt;Args&gt;(args)...),
-</pre></blockquote>
-</li>
-</ul>
-<p>
-I suggest to add qualification in all those places. As far as I know,
-these are all the remaining places in the whole library that explicitly
-use a placement new-expression. Should other uses come out, they should
-be qualified as well.
-</p>
-<p>
-As an aside, a qualified placement new-expression does not need
-additional requirements to be compiled in a constrained context. By
-adding qualification, the <tt>HasPlacementNew</tt> concept introduced recently in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2677.pdf">N2677 (Foundational Concepts)</a>
-would no longer be needed by library and
-should therefore be removed.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Replace "<tt>new</tt>" with "<tt>::new</tt>" in:
-</p>
-<ul>
-<li>
-20.7.10.1 [uninitialized.copy], paragraphs 1 and 3
-</li>
-<li>
-20.7.10.2 [uninitialized.fill] paragraph 1
-</li>
-<li>
-20.7.10.3 [uninitialized.fill.n] paragraph 1
-</li>
-<li>
-20.7.12.2.6 [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2.
-</li>
-</ul>
-
-
-
-
-
-
-<hr>
-<h3><a name="867"></a>867. Valarray and value-initialization</h3>
-<p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-From 26.5.2.1 [valarray.cons], paragraph 2:
-</p>
-
-<blockquote><pre>explicit valarray(size_t);
-</pre>
-<blockquote>
-The array created by this constructor has a length equal to the value of the argument. The elements
-of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
-</blockquote>
-</blockquote>
-
-<p>
-The problem is that the most obvious <tt>T</tt>s for <tt>valarray</tt> are <tt>float</tt>
-and <tt>double</tt>, they don't have a default constructor. I guess the intent is to value-initialize
-the elements, so I suggest replacing:
-</p>
-
-<blockquote>
-The elements of the array are constructed using the default constructor for the instantiating type <tt>T</tt>.
-</blockquote>
-<p>
-with
-</p>
-<blockquote>
-The elements of the array are value-initialized.
-</blockquote>
-
-<p>
-There is another reference to the default constructor of <tt>T</tt> in the non-normative note in paragraph 9.
-That reference should also be replaced. (The normative wording in paragraph 8 refers to <tt>T()</tt>
-and so it doesn't need changes).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.5.2.1 [valarray.cons], paragraph 2:
-</p>
-
-<blockquote>
-<pre>explicit valarray(size_t);
-</pre>
-<blockquote>
-The array created by this constructor has a length equal to the value of the argument. The elements
-of the array are <del>constructed using the default constructor for the instantiating type <tt>T</tt></del>
-<ins>value-initialized (8.5 [dcl.init])</ins>.
-</blockquote>
-</blockquote>
-
-<p>
-Change 26.5.2.7 [valarray.members], paragraph 9:
-</p>
-
-<blockquote>
-[<i>Example:</i> If the argument has the value -2, the first two elements of the result will be <del>constructed using the
-default constructor</del>
-<ins>value-initialized (8.5 [dcl.init])</ins>;
-the third element of the result will be assigned the value of the first element of the argument; etc. <i>-- end example</i>]
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="868"></a>868. default construction and value-initialization</h3>
-<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2008-07-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The term "default constructed" is often used in wording that predates
-the introduction of the concept of value-initialization. In a few such
-places the concept of value-initialization is more correct than the
-current wording (for example when the type involved can be a built-in)
-so a replacement is in order. Two of such places are already covered by
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>. This issue deliberately addresses the hopefully
-non-controversial changes in the attempt of being approved more quickly.
-A few other occurrences (for example in <tt>std::tuple</tt>,
-<tt>std::reverse_iterator</tt> and <tt>std::move_iterator</tt>) are left to separate
-issues. For <tt>std::reverse_iterator</tt>, see also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#408">408</a>. This issue is
-related with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.1.1 [utility.arg.requirements], paragraph 2:
-</p>
-
-<blockquote>
-In general, a default constructor is not required. Certain container class member function signatures specify
-<del>the default constructor</del>
-<ins><tt>T()</tt></ins>
-as a default argument. <tt>T()</tt> shall be a well-defined expression (8.5 [dcl.init]) if one of
-those signatures is called using the default argument (8.3.6 [dcl.fct.default]).
-</blockquote>
-
-<p>
-In all the following paragraphs in clause 23 [containers], replace "default constructed" with "value-initialized
-(8.5 [dcl.init])":
-</p>
-
-<ul>
-<li>23.2.2.1 [deque.cons] para 2</li>
-<li>23.2.2.2 [deque.capacity] para 1</li>
-<li>23.2.3.1 [forwardlist.cons] para 3</li>
-<li>23.2.3.4 [forwardlist.modifiers] para 21</li>
-<li>23.2.4.1 [list.cons] para 3</li>
-<li>23.2.4.2 [list.capacity] para 1</li>
-<li>23.2.6.1 [vector.cons] para 3</li>
-<li>23.2.6.2 [vector.capacity] para 10</li>
-</ul>
-
-
-
-
-
-<hr>
-<h3><a name="869"></a>869. Bucket (local) iterators and iterating past end</h3>
-<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Sohail Somani <b>Date:</b> 2008-07-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Is there any language in the current draft specifying the behaviour of the following snippet?
-</p>
-
-<blockquote><pre>unordered_set&lt;int&gt; s;
-unordered_set&lt;int&gt;::local_iterator it = s.end(0);
-
-// Iterate past end - the unspecified part
-it++;
-</pre></blockquote>
-
-<p>
-I don't think there is anything about <tt>s.end(n)</tt> being considered an
-iterator for the past-the-end value though (I think) it should be.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change Table 97 "Unordered associative container requirements" in 23.1.5 [unord.req]:
-</p>
-
-<blockquote>
-<table border="1">
-<caption>Table 97: Unordered associative container requirements</caption>
-<tbody><tr>
-<th>expression</th><th>return type</th><th>assertion/note pre/post-condition</th><th>complexity</th>
-</tr>
-<tr>
-<td><tt>b.begin(n)</tt></td>
-<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
-<td>Pre: n shall be in the range [0,b.bucket_count()). <del>Note: [b.begin(n), b.end(n)) is a
-valid range containing all of the elements in the n<sup>th</sup> bucket.</del>
-<ins><tt>b.begin(n)</tt> returns an iterator referring to the first element in the bucket.
-If the bucket is empty, then <tt>b.begin(n) == b.end(n)</tt>.</ins></td>
-<td>Constant</td>
-</tr>
-<tr>
-<td><tt>b.end(n)</tt></td>
-<td><tt>local_iterator</tt><br><tt>const_local_iterator</tt> for const <tt>b</tt>.</td>
-<td>Pre: n shall be in the range <tt>[0, b.bucket_count())</tt>.
-<ins><tt>b.end(n)</tt> returns an iterator which is the past-the-end value for the bucket.</ins></td>
-<td>Constant</td>
-</tr>
-</tbody></table>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="870"></a>870. Do unordered containers not support function pointers for predicate/hasher?</h3>
-<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-08-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Good ol' associative containers allow both function pointers and
-function objects as feasible
-comparators, as described in 23.1.4 [associative.reqmts]/2:
-</p>
-
-<blockquote>
-Each associative container is parameterized on <tt>Key</tt> and an ordering
-relation <tt>Compare</tt> that
-induces a strict weak ordering (25.3) on elements of Key. [..]. The
-object of type <tt>Compare</tt> is
-called the comparison object of a container. This comparison object
-may be a pointer to
-function or an object of a type with an appropriate function call operator.[..]
-</blockquote>
-
-<p>
-The corresponding wording for unordered containers is not so clear,
-but I read it to disallow
-function pointers for the hasher and I miss a clear statement for the
-equality predicate, see
-23.1.5 [unord.req]/3+4+5:
-</p>
-
-<blockquote>
-<p>
-Each unordered associative container is parameterized by <tt>Key</tt>, by a
-function object <tt>Hash</tt> that
-acts as a hash function for values of type <tt>Key</tt>, and by a binary
-predicate <tt>Pred</tt> that induces an
-equivalence relation on values of type <tt>Key</tt>.[..]
-</p>
-<p>
-A hash function is a function object that takes a single argument of
-type <tt>Key</tt> and returns a
-value of type <tt>std::size_t</tt>.
-</p>
-<p>
-Two values <tt>k1</tt> and <tt>k2</tt> of type <tt>Key</tt> are considered equal if the
-container's equality function object
-returns <tt>true</tt> when passed those values.[..]
-</p>
-</blockquote>
-
-<p>
-and table 97 says in the column "assertion...post-condition" for the
-expression X::hasher:
-</p>
-
-<blockquote>
-<tt>Hash</tt> shall be a unary function object type such that the expression
-<tt>hf(k)</tt> has type <tt>std::size_t</tt>.
-</blockquote>
-
-<p>
-Note that 20.6 [function.objects]/1 defines as "Function objects are
-objects with an <tt>operator()</tt> defined.[..]"
-</p>
-<p>
-Does this restriction exist by design or is it an oversight? If an
-oversight, I suggest that to apply
-the following
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 23.1.5 [unord.req]/3, just after the second sentence which is written as
-</p>
-
-<blockquote>
-Additionally, <tt>unordered_map</tt> and <tt>unordered_multimap</tt> associate an
-arbitrary mapped type <tt>T</tt> with the <tt>Key</tt>.
-</blockquote>
-
-<p>
-add one further sentence:
-</p>
-
-<blockquote>
-Both <tt>Hash</tt> and <tt>Pred</tt> may be pointers to function or objects of a type
-with an appropriate function call operator.
-</blockquote>
-
-<p>
-[Note1: Since the detailed requirements for <tt>Pred</tt> and <tt>Hash</tt> are given in
-p.4 and p.5, it an alternative resolution
-would be to insert a new paragraph just after p.5, which contains the
-above proposed sentence]
-</p>
-<p>
-[Note2: I do not propose a change of above quoted element in table 97,
-because the mis-usage of the
-notion of "function object" seems already present in the standard at
-several places, even if it includes
-function pointers, see e.g. 25 [algorithms]/7. The important point is
-that in those places a statement is
-given that the actually used symbol, like "Predicate" applies for
-function pointers as well]
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="871"></a>871. Iota's requirements on T are too strong</h3>
-<p><b>Section:</b> 26.6.5 [numeric.iota] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-08-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-According to the recent WP
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">N2691</a>,
-26.6.5 [numeric.iota]/1, the requires clause
-of <tt>std::iota</tt> says:
-</p>
-
-<blockquote>
-<tt>T</tt> shall meet the requirements of <tt>CopyConstructible</tt> and <tt>Assignable</tt> types, and
-shall be convertible to <tt>ForwardIterator</tt>'s value type.[..]
-</blockquote>
-
-<p>
-Neither <tt>CopyConstructible</tt> nor <tt>Assignable</tt> is needed, instead <tt>MoveConstructible</tt>
-seems to be the correct choice. I guess the current wording resulted as an
-artifact from comparing it with similar numerical algorithms like <tt>accumulate</tt>.
-</p>
-
-<p>
-Note: If this function will be conceptualized, the here proposed
-<tt>MoveConstructible</tt>
-requirement can be removed, because this is an implied requirement of
-function arguments, see
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2710.pdf">N2710</a>/[temp.req.impl]/3, last bullet.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change the first sentence of 26.6.5 [numeric.iota]/1:
-</p>
-
-<blockquote>
-<i>Requires:</i> <tt>T</tt> shall <del>meet the requirements of
-<tt>CopyConstructible</tt> and <tt>Assignable</tt> types,</del>
-<ins>
-be <tt>MoveConstructible</tt> (Table 34)
-</ins>
-and shall be
-convertible to <tt>ForwardIterator</tt>'s value type. [..]
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="872"></a>872. <tt>move_iterator::operator[]</tt> has wrong return type</h3>
-<p><b>Section:</b> 24.4.3.3.12 [move.iter.op.index] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Doug Gregor <b>Date:</b> 2008-08-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>move_iterator</tt>'s <tt>operator[]</tt> is declared as:
-</p>
-
-<blockquote><pre>reference operator[](difference_type n) const;
-</pre></blockquote>
-
-<p>
-This has the same problem that <tt>reverse_iterator</tt>'s <tt>operator[]</tt> used to
-have: if the underlying iterator's <tt>operator[]</tt> returns a proxy, the
-implicit conversion to <tt>value_type&amp;&amp;</tt> could end up referencing a temporary
-that has already been destroyed. This is essentially the same issue that
-we dealt with for <tt>reverse_iterator</tt> in DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#386">386</a>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 24.4.3.1 [move.iterator] and 24.4.3.3.12 [move.iter.op.index], change the declaration of
-<tt>move_iterator</tt>'s <tt>operator[]</tt> to:
-</p>
-
-<blockquote><pre><del>reference</del> <ins><i>unspecified</i></ins> operator[](difference_type n) const;
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="873"></a>873. signed integral type and unsigned integral type are not clearly defined</h3>
-<p><b>Section:</b> 3.9.1 [basic.fundamental] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Travis Vitek <b>Date:</b> 2008-06-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
- Neither the term "signed integral type" nor the term "unsigned
- integral type" is defined in the core language section of the
- standard, therefore the library section should avoid its use. The
- terms <i>signed integer type</i> and <i>unsigned integer type</i> are
- indeed defined (in 3.9.1 [basic.fundamental]), thus the usages should be
- replaced accordingly.
- </p>
-
- <p>
- Note that the key issue here is that "signed" + "integral type" !=
- "signed integral type".
-
- The types <code>bool</code>, <code>char</code>, <code>char16_t</code>,
- <code>char32_t</code> and <code>wchar_t</code> are all listed as
- integral types, but are neither of <i>signed integer type</i> or
- <i>unsigned integer type</i>. According to 3.9 [basic.types] p7, a synonym for
- integral type is <i>integer type</i>.
-
- Given this, one may choose to assume that an <i>integral type</i> that
- can represent values less than zero is a <i>signed integral type</i>.
- Unfortunately this can cause ambiguities.
-
- As an example, if <code>T</code> is <code>unsigned char</code>, the
- expression <code>make_signed&lt;T&gt;::type</code>, is supposed to
- name a signed integral type. There are potentially two types that
- satisfy this requirement, namely <code>signed char</code> and
- <code>char</code> (assuming <code>CHAR_MIN &lt; 0</code>).
- </p>
-
-
- <p><b>Proposed resolution:</b></p>
- <p>
- I propose to use the terms "signed integer type" and "unsigned integer
- type" in place of "signed integral type" and "unsigned integral type"
- to eliminate such ambiguities.
- </p>
-
- <p>
- The proposed change makes it absolutely clear that the difference
- between two pointers cannot be <tt>char</tt> or <tt>wchar_t</tt>,
- but could be any of the signed integer types.
- 5.7 [expr.add] paragraph 6...
- </p>
- <blockquote>
- <p>
- </p><ol>
- <li>
- When two pointers to elements of the same array object are
- subtracted, the result is the difference of the subscripts of
- the two array elements. The type of the result is an
- implementation-defined <del>signed integral
- type</del><ins>signed integer type</ins>; this type shall be the
- same type that is defined as <code>std::ptrdiff_t</code> in the
- <code>&lt;cstdint&gt;</code> header (18.1)...
- </li>
- </ol>
-
- </blockquote>
-
- <p>
- The proposed change makes it clear that <tt>X::size_type</tt> and
- <tt>X::difference_type</tt> cannot be <tt>char</tt> or
- <tt>wchar_t</tt>, but could be one of the signed or unsigned integer
- types as appropriate.
- 20.1.2 [allocator.requirements] table 40...
- </p>
- <blockquote>
- Table 40: Allocator requirements
- <table border="1">
- <thead>
- <tr>
- <th>expression</th>
- <th>return type</th>
- <th>assertion/note/pre/post-condition</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td><tt>X::size_type</tt></td>
- <td>
- <del>unsigned integral type</del>
- <ins>unsigned integer type</ins>
- </td>
- <td>a type that can represent the size of the largest object in
- the allocation model.</td>
- </tr>
- <tr>
- <td><tt>X::difference_type</tt></td>
- <td>
- <del>signed integral type</del>
- <ins>signed integer type</ins>
- </td>
- <td>a type that can represent the difference between any two
- pointers in the allocation model.</td>
- </tr>
- </tbody>
- </table>
- </blockquote>
-
- <p>
- The proposed change makes it clear that <tt>make_signed&lt;T&gt;::type</tt>
- must be one of the signed integer types as defined in 3.9.1. Ditto for
- <tt>make_unsigned&lt;T&gt;type</tt> and unsigned integer types.
- 20.5.6.3 [meta.trans.sign] table 48...
- </p>
- <blockquote>
- Table 48: Sign modifications
- <table border="1">
- <thead>
- <tr>
- <th>Template</th>
- <th>Comments</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>
- <tt>template &lt;class T&gt; struct make_signed;</tt>
- </td>
- <td>
- If <code>T</code> names a (possibly cv-qualified) <del>signed
- integral type</del><ins>signed integer type</ins> (3.9.1) then
- the member typedef <code>type</code> shall name the type
- <code>T</code>; otherwise, if <code>T</code> names a (possibly
- cv-qualified) <del>unsigned integral type</del><ins>unsigned
- integer type</ins> then <code>type</code> shall name the
- corresponding <del>signed integral type</del><ins>signed
- integer type</ins>, with the same cv-qualifiers as
- <code>T</code>; otherwise, <code>type</code> shall name the
- <del>signed integral type</del><ins>signed integer type</ins>
- with the smallest rank (4.13) for which <code>sizeof(T) ==
- sizeof(type)</code>, with the same cv-qualifiers as
- <code>T</code>.
-
- <i>Requires:</i> <code>T</code> shall be a (possibly
- cv-qualified) integral type or enumeration but not a
- <code>bool</code> type.
- </td>
- </tr>
- <tr>
- <td>
- <tt>template &lt;class T&gt; struct make_unsigned;</tt>
- </td>
- <td>
- If <code>T</code> names a (possibly cv-qualified)
- <del>unsigned integral type</del><ins>unsigned integer
- type</ins> (3.9.1) then the member typedef <code>type</code>
- shall name the type <code>T</code>; otherwise, if
- <code>T</code> names a (possibly cv-qualified) <del>signed
- integral type</del><ins>signed integer type</ins> then
- <code>type</code> shall name the corresponding <del>unsigned
- integral type</del><ins>unsigned integer type</ins>, with the
- same cv-qualifiers as <code>T</code>; otherwise,
- <code>type</code> shall name the <del>unsigned integral
- type</del><ins>unsigned integer type</ins> with the smallest
- rank (4.13) for which <code>sizeof(T) == sizeof(type)</code>,
- with the same cv-qualifiers as <code>T</code>.
-
- <i>Requires:</i> <code>T</code> shall be a (possibly
- cv-qualified) integral type or enumeration but not a
- <code>bool</code> type.
- </td>
- </tr>
- </tbody>
- </table>
- </blockquote>
-
-
- <p>
- Note: I believe that the basefield values should probably be
- prefixed with <tt>ios_base::</tt> as they are in 22.2.2.2.2 [facet.num.put.virtuals]
-
- The listed virtuals are all overloaded on signed and unsigned integer
- types, the new wording just maintains consistency.
-
- 22.2.2.1.2 [facet.num.get.virtuals] table 78...
- </p>
- <blockquote>
- Table 78: Integer Conversions
- <table border="1">
- <thead>
- <tr>
- <th>State</th>
- <th><tt>stdio</tt> equivalent</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td><tt>basefield == oct</tt></td>
- <td><tt>%o</tt></td>
- </tr>
- <tr>
- <td><tt>basefield == hex</tt></td>
- <td><tt>%X</tt></td>
- </tr>
- <tr>
- <td><tt>basefield == 0</tt></td>
- <td><tt>%i</tt></td>
- </tr>
- <tr>
- <td><del>signed integral type</del><ins>signed integer
- type</ins></td>
- <td><tt>%d</tt></td>
- </tr>
- <tr>
- <td><del>unsigned integral type</del><ins>unsigned integer
- type</ins></td>
- <td><tt>%u</tt></td>
- </tr>
- </tbody>
- </table>
- </blockquote>
-
-
-
- <p>
- Rationale is same as above.
- 22.2.2.2.2 [facet.num.put.virtuals] table 80...
- </p>
- <blockquote>
- Table 80: Integer Conversions
- <table border="1">
- <thead>
- <tr>
- <th>State</th>
- <th><tt>stdio</tt> equivalent</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td><tt>basefield == ios_base::oct</tt></td>
- <td><tt>%o</tt></td>
- </tr>
- <tr>
- <td><tt>(basefield == ios_base::hex) &amp;&amp;
- !uppercase</tt></td>
- <td><tt>%x</tt></td>
- </tr>
- <tr>
- <td><tt>(basefield == ios_base::hex)</tt></td>
- <td><tt>%X</tt></td>
- </tr>
- <tr>
- <td><tt>basefield == 0</tt></td>
- <td><tt>%i</tt></td>
- </tr>
- <tr>
- <td>for a <del>signed integral type</del><ins>signed integer
- type</ins></td>
- <td><tt>%d</tt></td>
- </tr>
- <tr>
- <td>for a <del>unsigned integral type</del><ins>unsigned integer
- type</ins></td>
- <td><tt>%u</tt></td>
- </tr>
- </tbody>
- </table>
- </blockquote>
-
-
- <p>
- 23.1 [container.requirements] table 80...
- </p>
- <blockquote>
- Table 89: Container requirements
- <table border="1">
- <thead>
- <tr>
- <th>expression</th>
- <th>return type</th>
- <th>operational semantics</th>
- <th>assertion/note/pre/post-condition</th>
- <th>complexity</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td><tt>X::difference_type</tt></td>
- <td><del>signed integral type</del><ins>signed integer type</ins></td>
- <td>&nbsp;</td>
- <td>is identical to the difference type of <tt>X::iterator</tt>
- and <tt>X::const_iterator</tt></td>
- <td>compile time</td>
- </tr>
- <tr>
- <td><tt>X::size_type</tt></td>
- <td><del>unsigned integral type</del><ins>unsigned integer type</ins></td>
- <td>&nbsp;</td>
- <td><tt>size_type</tt> can represent any non-negative value of
- <tt>difference_type</tt></td>
- <td>compile time</td>
- </tr>
- </tbody>
- </table>
- </blockquote>
-
- <p>
- 24.1 [iterator.requirements] paragraph 1...
- </p>
- <blockquote>
- Iterators are a generalization of pointers that allow a C++ program to
- work with different data structures (containers) in a uniform manner.
- To be able to construct template algorithms that work correctly and
- efficiently on different types of data structures, the library
- formalizes not just the interfaces but also the semantics and
- complexity assumptions of iterators. All input iterators
- <code>i</code> support the expression <code>*i</code>, resulting in a
- value of some class, enumeration, or built-in type <code>T</code>,
- called the <i>value type</i> of the iterator. All output iterators
- support the expression <code>*i = o</code> where <code>o</code> is a
- value of some type that is in the set of types that are
- <i>writable</i> to the particular iterator type of <code>i</code>. All
- iterators <code>i</code> for which the expression <code>(*i).m</code>
- is well-defined, support the expression <code>i-&gt;m</code> with the
- same semantics as <code>(*i).m</code>. For every iterator type
- <code>X</code> for which equality is defined, there is a corresponding
- <del>signed integral type</del> <ins>signed integer type</ins> called
- the <i>difference type</i> of the iterator.
- </blockquote>
-
- <p>
- I'm a little unsure of this change. Previously this paragraph would
- allow instantiations of <tt>linear_congruential_engine</tt> on
- <tt>char</tt>, <tt>wchar_t</tt>, <tt>bool</tt>, and other types. The
- new wording prohibits this.
- 26.4.3.1 [rand.eng.lcong] paragraph 2...
- </p>
- <blockquote>
- The template parameter <code>UIntType</code> shall denote an
- <del>unsigned integral type</del><ins>unsigned integer type</ins>
- large enough to store values as large as <code>m - 1</code>. If the
- template parameter <code>m</code> is 0, the modulus <code>m</code>
- used throughout this section 26.4.3.1 is
- <code>numeric_limits&lt;result_type&gt;::max()</code> plus 1. [Note:
- The result need not be representable as a value of type
- <code>result_type</code>. --end note] Otherwise, the following
- relations shall hold: <code>a &lt; m</code> and <code>c &lt;
- m</code>.
- </blockquote>
-
- <p>
- Same rationale as the previous change.
- 26.4.4.4 [rand.adapt.xor] paragraph 6...
- </p>
- <blockquote>
- Both <code>Engine1::result_type</code> and
- <code>Engine2::result_type</code> shall denote (possibly different)
- <del>unsigned integral types</del><ins>unsigned integer types</ins>.
- The member <i>result_type</i> shall denote either the type
- <i>Engine1::result_type</i> or the type <i>Engine2::result_type</i>,
- whichever provides the most storage according to clause 3.9.1.
- </blockquote>
-
- <p>
- 26.4.7.1 [rand.util.seedseq] paragraph 7...
- </p>
- <blockquote>
- <i>Requires:</i><code>RandomAccessIterator</code> shall meet the
- requirements of a random access iterator (24.1.5) such that
- <code>iterator_traits&lt;RandomAccessIterator&gt;::value_type</code>
- shall denote an <del>unsigned integral type</del><ins>unsigned integer
- type</ins> capable of accomodating 32-bit quantities.
- </blockquote>
-
- <p>
- By making this change, integral types that happen to have a signed
- representation, but are not signed integer types, would no longer be
- required to use a two's complement representation. This may go against
- the original intent, and should be reviewed.
- 29.4 [atomics.types.operations] paragraph 24...
- </p>
- <blockquote>
- <i>Remark:</i> For <del>signed integral types</del><ins>signed integer
- types</ins>, arithmetic is defined using two's complement
- representation. There are no undefined results. For address types, the
- result may be an undefined address, but the operations otherwise have
- no undefined behavior.
- </blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="874"></a>874. Missing <tt>initializer_list</tt> constructor for <tt>discrete_distribution</tt></h3>
-<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-08-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-During the Sophia Antipolis meeting it was decided to separate from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a> a
-subrequest that adds initializer list support to
-<tt>discrete_distribution</tt>, specifically,
-the issue proposed to add a c'tor taking a <tt>initializer_list&lt;double&gt;</tt>.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>
-In 26.4.8.5.1 [rand.dist.samp.discrete]/1, class <tt>discrete_distribution</tt>,
-just <em>before</em> the member declaration
-</p>
-
-<blockquote><pre>explicit discrete_distribution(const param_type&amp; parm);
-</pre></blockquote>
-
-<p>
-insert
-</p>
-
-<blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; wl);
-</pre></blockquote>
-</li>
-
-<li>
-<p>
-Between p.4 and p.5 of the same section insert a new
-paragraph as part of the new member description:
-</p>
-
-<blockquote><pre>discrete_distribution(initializer_list&lt;double&gt; wl);
-</pre>
-
-<blockquote>
-<i>Effects:</i> Same as <tt>discrete_distribution(wl.begin(), wl.end())</tt>.
-</blockquote>
-</blockquote>
-</li>
-</ol>
-
-
-
-
-
-<hr>
-<h3><a name="875"></a>875. Missing <tt>initializer_list</tt> constructor for <tt>piecewise_constant_distribution</tt></h3>
-<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-08-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-During the Sophia Antipolis meeting it was decided to separate from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a> a subrequest that adds initializer list support to
-<tt>piecewise_constant_distribution</tt>, specifically, the issue proposed
-to add a c'tor taking a <tt>initializer_list&lt;double&gt;</tt> and a <tt>Callable</tt> to evaluate
-weight values. For consistency with the remainder of this class and
-the remainder of the <tt>initializer_list</tt>-aware library the author decided to
-change the list argument type to the template parameter <tt>RealType</tt>
-instead. For the reasoning to use <tt>Func</tt> instead of <tt>Func&amp;&amp;</tt> as c'tor
-function argument see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>
-In 26.4.8.5.2 [rand.dist.samp.pconst]/1, class <tt>piecewise_constant_distribution</tt>,
-just <em>before</em> the member declaration
-</p>
-
-<blockquote><pre>explicit piecewise_constant_distribution(const param_type&amp; parm);
-</pre></blockquote>
-
-<p>
-insert
-</p>
-
-<blockquote><pre>template&lt;typename Func&gt;
-piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
-</pre></blockquote>
-</li>
-
-<li>
-<p>
-Between p.4 and p.5 of the same section insert a series of
-new paragraphs nominated below as [p5_1], [p5_2], and [p5_3]
-as part of the new member description:
-</p>
-
-<blockquote><pre>template&lt;typename Func&gt;
-piecewise_constant_distribution(initializer_list&lt;RealType&gt; bl, Func fw);
-</pre>
-
-<blockquote>
-
-<p>
-[p5_1] <i>Complexity:</i> Exactly <tt>nf = max(bl.size(), 1) - 1</tt> invocations of <tt>fw</tt>.
-</p>
-
-<p>
-[p5_2] <i>Requires:</i>
-</p>
-
-<ol type="a">
-<li>
-<tt>fw</tt> shall be callable with one argument of type <tt>RealType</tt>, and shall
- return values of a type convertible to <tt>double</tt>;
-</li>
-<li>
-The relation <tt>0 &lt; S = w<sub>0</sub>+. . .+w<sub>n-1</sub></tt> shall hold.
-For all sampled values <tt><i>x<sub>k</sub></i></tt> defined below, <tt>fw(<i>x<sub>k</sub></i>)</tt> shall return a weight
- value <tt><i>w<sub>k</sub></i></tt> that is non-negative, non-NaN, and non-infinity;
-</li>
-<li>
-If <tt>nf &gt; 0</tt> let <tt>b<sub><i>k</i></sub> = *(bl.begin() + k), k = 0, . . . , bl.size()-1</tt> and the
-following relations shall hold for <tt>k = 0, . . . , nf-1: b<sub><i>k</i></sub> &lt; b<sub><i>k+1</i></sub></tt>.
-</li>
-</ol>
-
-<p>
-[p5_3] <i>Effects:</i>
-</p>
-
-<ol type="a">
-<li>
-<p>If <tt>nf == 0</tt>,</p>
-<ol type="a">
-<li>
-lets the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist of the single
- value <tt>w<sub>0</sub> = 1</tt>, and
-</li>
-<li>
-lets the sequence <tt>b</tt> have length <tt>n+1</tt> with <tt>b<sub>0</sub> = 0</tt> and <tt>b<sub>1</sub> = 1</tt>.
-</li>
-</ol>
-</li>
-
-<li>
-<p>Otherwise,</p>
-<ol type="a">
-<li>
-sets <tt>n = nf</tt>, and <tt>[bl.begin(), bl.end())</tt> shall form the sequence <tt>b</tt> of
-length <tt>n+1</tt>, and
-</li>
-<li>
-<p>lets the sequences <tt>w</tt> have length <tt>n</tt> and for each <tt>k = 0, . . . ,n-1</tt>,
- calculates:</p>
-<blockquote><pre>x<sub><i>k</i></sub> = 0.5*(b<sub><i>k+1</i></sub> + b<sub><i>k</i></sub>)
-w<sub><i>k</i></sub> = fw(x<sub><i>k</i></sub>)
-</pre></blockquote>
-</li>
-</ol>
-</li>
-
-<li>
-<p>
-Constructs a <tt>piecewise_constant_distribution</tt> object with
-the above computed sequence <tt>b</tt> as the interval boundaries
-and with the probability densities:
-</p>
-<blockquote><pre>&#961;<sub><i>k</i></sub> = w<sub><i>k</i></sub>/(S * (b<sub><i>k+1</i></sub> - b<sub><i>k</i></sub>)) for k = 0, . . . , n-1.
-</pre></blockquote>
-
-</li>
-</ol>
-
-</blockquote>
-</blockquote>
-</li>
-</ol>
-
-
-
-
-
-<hr>
-<h3><a name="876"></a>876. <tt>basic_string</tt> access operations should give stronger guarantees</h3>
-<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-08-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-During the Sophia Antipolis meeting it was decided to split-off some
-parts of the
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2647.html">n2647</a>
-("Concurrency modifications for <tt>basic_string</tt>")
-proposal into a separate issue, because these weren't actually
-concurrency-related. The here proposed changes refer to the recent
-update document
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm">n2668</a>
-and attempt to take advantage of the
-stricter structural requirements.
-</p>
-<p>
-Indeed there exists some leeway for more guarantees that would be
-very useful for programmers, especially if interaction with transactionary
-or exception-unaware C API code is important. This would also allow
-compilers to take advantage of more performance optimizations, because
-more functions can have throw() specifications. This proposal uses the
-form of "Throws: Nothing" clauses to reach the same effect, because
-there already exists a different issue in progress to clean-up the current
-existing "schizophrenia" of the standard in this regard.
-</p>
-<p>
-Due to earlier support for copy-on-write, we find the following
-unnecessary limitations for C++0x:
-</p>
-
-<ol>
-<li>
-Missing no-throw guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
-a pointer to their guts, which is a non-failure operation. This should
-be spelled out. It is also noteworthy to mention that the same
-guarantees should also be given by the size query functions,
-because the combination of pointer to content and the length is
-typically needed during interaction with low-level API.
-</li>
-<li>
-Missing complexity guarantees: <tt>data()</tt> and <tt>c_str()</tt> simply return
-a pointer to their guts, which is guaranteed O(1). This should be
-spelled out.
-</li>
-<li>
-Missing reading access to the terminating character: Only the
-const overload of <tt>operator[]</tt> allows reading access to the terminator
-char. For more intuitive usage of strings, reading access to this
-position should be extended to the non-const case. In contrast
-to C++03 this reading access should now be homogeneously
-an lvalue access.
-</li>
-</ol>
-
-<p>
-The proposed resolution is split into a main part (A) and a
-secondary part (B) (earlier called "Adjunct Adjunct Proposal").
-(B) extends (A) by also making access to index position
-size() of the at() overloads a no-throw operation. This was
-separated, because this part is theoretically observable in
-specifically designed test programs.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<ol type="A">
-<li>
-<ol>
-<li>
-<p>In 21.3.4 [string.capacity], just after p. 1 add a new paragraph:
-</p>
-<blockquote>
-<i>Throws:</i> Nothing.
-</blockquote>
-
-</li>
-<li>
-<p>
-In 21.3.5 [string.access] <em>replace</em> p. 1 by the following <em>4</em> paragraghs:
-</p>
-
-<blockquote>
-<p>
-<i>Requires:</i> <tt>pos &#8804; size()</tt>.
-</p>
-<p>
-<i>Returns:</i> If <tt>pos &lt; size()</tt>, returns <tt>*(begin() + pos)</tt>. Otherwise, returns
-a reference to a <tt>charT()</tt> that shall not be modified.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-<p>
-<i>Complexity:</i> Constant time.
-</p>
-</blockquote>
-
-</li>
-<li>
-<p>
-In 21.3.7.1 [string.accessors] replace the now <em>common</em> returns
-clause of <tt>c_str()</tt> and <tt>data()</tt> by the following <em>three</em> paragraphs:
-</p>
-<blockquote>
-<p>
-<i>Returns:</i> A pointer <tt>p</tt> such that <tt>p+i == &amp;operator[](i)</tt> for each <tt>i</tt>
-in <tt>[0, size()]</tt>.
-</p>
-<p>
-<i>Throws:</i> Nothing.
-</p>
-<p>
-<i>Complexity:</i> Constant time.
-</p>
-</blockquote>
-</li>
-</ol>
-</li>
-<li>
-<ol start="4">
-<li>
-<p>
-In 21.3.5 [string.access] <em>replace</em> p.2 and p.3 by:
-</p>
-<blockquote>
-<p>
-<i>Requires:</i> <tt>pos &#8804; size()</tt>
-</p>
-<p>
-<i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.
-</p>
-</blockquote>
-</li>
-</ol>
-</li>
-</ol>
-
-
-
-
-
-
-<hr>
-<h3><a name="877"></a>877. to <tt>throw()</tt> or to <i>Throw:</i> Nothing.</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-08-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-Recent changes to
-the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf">working
-draft</a> have introduced a gratuitous inconsistency with the C++ 2003
-version of the specification with respect to exception guarantees
-provided by standard functions. While the C++ 2003 standard
-consistenly uses the empty exception specification, <tt>throw()</tt>,
-to declare functions that are guaranteed not to throw exceptions, the
-current working draft contains a number of "<i>Throws:</i> Nothing."
-clause to specify essentially the same requirement. The difference
-between the two approaches is that the former specifies the behavior
-of programs that violate the requirement (<tt>std::unexpected()</tt>
-is called) while the latter leaves the behavior undefined.
-
- </p>
- <p>
-
-A survey of the working draft reveals that there are a total of 209
-occurrences of <tt>throw()</tt> in the library portion of the spec,
-the majority in clause 18, a couple (literally) in 19, a handful in
-20, a bunch in 22, four in 24, one in 27, and about a dozen in D.9.
-
- </p>
- <p>
-
-There are also 203 occurrences of "<i>Throws:</i> Nothing." scattered
-throughout the spec.
-
- </p>
- <p>
-
-While sometimes there are good reasons to use the "<i>Throws:</i>
-Nothing." approach rather than making use of <tt>throw()</tt>, these
-reasons do not apply in most of the cases where this new clause has
-been introduced and the empty exception specification would be a
-better approach.
-
- </p>
- <p>
-
-First, functions declared with the empty exception specification
-permit compilers to generate better code for calls to such
-functions. In some cases, the compiler might even be able to eliminate
-whole chunks of user-written code when instantiating a generic
-template on a type whose operations invoked from the template
-specialization are known not to throw. The prototypical example are
-the <tt>std::uninitialized_copy()</tt>
-and <tt>std::uninitialized_fill()</tt> algorithms where the
-entire <tt>catch(...)</tt> block can be optimized away.
-
- </p>
- <p>
-
-For example, given the following definition of
-the <tt>std::uninitialized_copy</tt> function template and a
-user-defined type <tt>SomeType</tt>:
-
- </p>
- <blockquote>
- <pre>template &lt;class InputIterator, class ForwardIterator&gt;
-ForwardIterator
-uninitialized_copy (InputIterator first, InputIterator last, ForwardIterator res)
-{
- typedef iterator_traits&lt;ForwardIterator&gt;::value_type ValueType;
-
- ForwardIterator start = res;
-
- try {
- for (; first != last; ++first, ++res)
- ::new (&amp;*res) ValueType (*first);
- }
- catch (...) {
- for (; start != res; --start)
- (&amp;*start)-&gt;~ValueType ();
- throw;
- }
- return res;
-}
-
-struct SomeType {
- SomeType (const SomeType&amp;) <ins>throw ()</ins>;
-}</pre>
- </blockquote>
- <p>
-
-compilers are able to emit the following efficient specialization
-of <tt>std::uninitialized_copy&lt;const SomeType*, SomeType*&gt;</tt>
-(note that the <tt>catch</tt> block has been optimized away):
-
- </p>
- <blockquote>
- <pre>template &lt;&gt; SomeType*
-uninitialized_copy (const SomeType *first, const SomeType *last, SomeType *res)
-{
- for (; first != last; ++first, ++res)
- ::new (res) SomeType (*first);
-
- return res;
-}</pre>
- </blockquote>
- <p>
-
-Another general example is default constructors which, when decorated
-with <tt>throw()</tt>, allow the compiler to eliminate the
-implicit <tt>try</tt> and <tt>catch</tt> blocks that it otherwise must
-emit around each the invocation of the constructor
-in <i>new-expressions</i>.
-
- </p>
- <p>
-
-For example, given the following definitions of
-class <tt>MayThrow</tt> and <tt>WontThrow</tt> and the two
-statements below:
-
- </p>
- <blockquote>
- <pre>struct MayThrow {
- MayThrow ();
-};
-
-struct WontThrow {
- WontThrow () <ins>throw ()</ins>;
-};
-
-MayThrow *a = new MayThrow [N];
-WontThrow *b = new WontThrow [N];</pre>
-
- </blockquote>
- <p>
-
-the compiler generates the following code for the first statement:
-
- </p>
- <blockquote>
- <pre>MayThrow *a;
-{
- MayThrow *first = operator new[] (N * sizeof (*a));
- MayThrow *last = first + N;
- MayThrow *next = first;
- try {
- for ( ; next != last; ++next)
- new (next) MayThrow;
- }
- catch (...) {
- for ( ; first != first; --next)
- next-&gt;~MayThrow ();
- operator delete[] (first);
- throw;
- }
- a = first;
-}</pre>
- </blockquote>
- <p>
-
-but it is can generate much more compact code for the second statement:
-
- </p>
- <blockquote>
- <pre>WontThrow *b = operator new[] (N * sizeof (*b));
-WontThrow *last = b + N;
-for (WontThrow *next = b; next != last; ++next)
- new (next) WontThrow;
-</pre>
- </blockquote>
- <p>
-
-Second, in order for users to get the maximum benefit out of the new
-<tt>std::has_nothrow_xxx</tt> traits when using standard library types
-it will be important for implementations to decorate all non throwing
-copy constructors and assignment operators with <tt>throw()</tt>. Note
-that while an optimizer may be able to tell whether a function without
-an explicit exception specification can throw or not based on its
-definition, it can only do so when it can see the source code of the
-definition. When it can't it must assume that the function may
-throw. To prevent violating the One Definition Rule,
-the <tt>std::has_nothrow_xxx</tt> trait must return the most
-pessimistic guess across all translation units in the program, meaning
-that <tt>std::has_nothrow_xxx&lt;T&gt;::value</tt> must evaluate to
-<tt>false</tt> for any <tt>T</tt> whose <tt>xxx</tt>
-(where <tt>xxx</tt> is default or copy ctor, or assignment operator)
-is defined out-of-line.
-
- </p>
- <p>
-
-<b>Counterarguments:</b>
-
- </p>
- <p>
-
-During the discussion of this issue
-on <a href="mailto:c++std-lib@accu.org">c++std-lib@accu.org</a>
-(starting with post <tt>c++std-lib-21950</tt>) the following arguments
-in favor of the "<i>Throws:</i> Nothing." style have been made.
-
- </p>
- <p>
- </p><ol>
- <li>
-
-Decorating functions that cannot throw with the empty exception
-specification can cause the compiler to generate suboptimal code for
-the implementation of the function when it calls other functions that
-aren't known to the compiler not to throw (i.e., that aren't decorated
-with <tt>throw()</tt> even if they don't actually throw). This is a
-common situation when the called function is a C or POSIX function.
-
- </li>
- <li>
-
-Alternate, proprietary mechanisms exist (such as
-GCC <a href="http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#index-g_t_0040code_007bnothrow_007d-function-attribute-2160"><tt>__attribute__((nothrow))</tt></a>
-or Visual
-C++ <a href="http://msdn.microsoft.com/en-us/library/49147z04%28VS.80%29.aspx"><tt>__declspec(nothrow)</tt></a>)
-that let implementers mark up non-throwing functions, often without
-the penalty mentioned in (1) above. The C++ standard shouldn't
-preclude the use of these potentially more efficient mechanisms.
-
- </li>
- <li>
-
-There are functions, especially function templates, that invoke
-user-defined functions that may or may not be
-declared <tt>throw()</tt>. Declaring such functions with the empty
-exception specification will cause compilers to generate suboptimal
-code when the user-defined function isn't also declared not to throw.
-
- </li>
- </ol>
-
- <p>
-
-The answer to point (1) above is that implementers can (and some have)
-declare functions with <tt>throw()</tt> to indicate to the compiler
-that calls to the function can safely be assumed not to throw in order
-to allow it to generate efficient code at the call site without also
-having to define the functions the same way and causing the compiler
-to generate suboptimal code for the function definition. That is, the
-function is declared with <tt>throw()</tt> in a header but it's
-defined without it in the source file. The <tt>throw()</tt>
-declaration is suppressed when compiling the definition to avoid
-compiler errors. This technique, while strictly speaking no permitted
-by the language, is safe and has been employed in practice. For
-example, the GNU C library takes this approach. Microsoft Visual C++
-takes a similar approach by simply assuming that no function with C
-language linkage can throw an exception unless it's explicitly
-declared to do so using the language extension <tt>throw(...)</tt>.
-
- </p>
- <p>
-
-Our answer to point (2) above is that there is no existing practice
-where C++ Standard Library implementers have opted to make use of the
-proprietary mechanisms to declare functions that don't throw. The
-language provides a mechanism specifically designed for this
-purpose. Avoiding its use in the specification itself in favor of
-proprietary mechanisms defeats the purpose of the feature. In
-addition, making use of the empty exception specification
-inconsistently, in some areas of the standard, while conspicuously
-avoiding it and making use of the "<i>Throws:</i> Nothing." form in
-others is confusing to users.
-
- </p>
- <p>
-
-The answer to point (3) is simply to exercise caution when declaring
-functions and especially function templates with the empty exception
-specification. Functions that required not to throw but that may call
-back into user code are poor candidates for the empty exception
-specification and should instead be specified using "<i>Throws:</i>
-Nothing." clause.
-
- </p>
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-We propose two possible solutions. Our recommendation is to adopt
-Option 1 below.
-
- </p>
- <p>
-
-<b>Option 1:</b>
-
- </p>
- <p>
-
-Except for functions or function templates that make calls back to
-user-defined functions that may not be declared <tt>throw()</tt>
-replace all occurrences of the "<i>Throws:</i> Nothing." clause with
-the empty exception specification. Functions that are required not to
-throw but that make calls back to user code should be specified to
-"<i>Throw:</i> Nothing."
-
- </p>
- <p>
-
-<b>Option 2:</b>
-
- </p>
- <p>
-
-For consistency, replace all occurrences of the empty exception
-specification with a "<i>Throws:</i> Nothing." clause.
-
- </p>
-
-
-
-
-<hr>
-<h3><a name="878"></a>878. <tt>forward_list</tt> preconditions</h3>
-<p><b>Section:</b> 23.2.3 [forwardlist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2008-08-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#New">New</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-<tt>forward_list</tt> member functions that take
-a <tt>forward_list::iterator</tt> (denoted <tt>position</tt> in the
-function signatures) argument have the following precondition:
-
- </p>
- <blockquote>
-
-<i>Requires:</i> <tt>position</tt> is dereferenceable or equal
-to <tt>before_begin()</tt>.
-
- </blockquote>
- <p>
-
-I believe what's actually intended is this:
-
- </p>
- <blockquote>
-
-<i>Requires:</i> <tt>position</tt> is in the range
-[<tt>before_begin()</tt>, <tt>end()</tt>).
-
- </blockquote>
- <p>
-
-That is, when it's dereferenceable, <tt>position</tt> must point
-into <tt>*this</tt>, not just any <tt>forward_list</tt> object.
-
- </p>
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-Change the <i>Requires</i> clause as follows:
-
- </p>
- <blockquote>
-
-<i>Requires:</i> <tt>position</tt> is <ins>in the range
-[<tt>before_begin()</tt>, <tt>end()</tt>)</ins> <del>dereferenceable
-or equal to <tt>before_begin()</tt></del>.
-
- </blockquote>
-
-
-
-
-</body></html> \ No newline at end of file
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-closed.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-closed.html
deleted file mode 100644
index a056c3ee2..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-closed.html
+++ /dev/null
@@ -1,14016 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
-<html><head>
-<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
-
-
-<title>C++ Standard Library Closed Issues List</title>
-<style type="text/css">
-p {text-align:justify}
-li {text-align:justify}
-ins {background-color:#A0FFA0}
-del {background-color:#FFA0A0}
-</style>
-</head><body>
-<table>
-<tbody><tr>
-<td align="left">Doc. no.</td>
-<td align="left">N2729=08-0239</td>
-</tr>
-<tr>
-<td align="left">Date:</td>
-<td align="left">2008-08-24</td>
-</tr>
-<tr>
-<td align="left">Project:</td>
-<td align="left">Programming Language C++</td>
-</tr>
-<tr>
-<td align="left">Reply to:</td>
-<td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
-</tr>
-</tbody></table>
-<h1>C++ Standard Library Closed Issues List (Revision R59)</h1>
-
- <p>Reference ISO/IEC IS 14882:1998(E)</p>
- <p>Also see:</p>
- <ul>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
- </ul>
-
- <p>This document contains only library issues which have been closed
- by the Library Working Group as duplicates or not defects. That is,
- issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> or
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> active issues and more
- information. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered
- defects. The introductory material in that document also applies to
- this document.</p>
-
-<h2>Revision History</h2>
-<ul>
-<li>R59:
-2008-08-22 pre-San Francisco mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>192 open issues, up by 9.</li>
-<li>686 closed issues, up by 0.</li>
-<li>878 issues total, up by 9.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R58:
-2008-07-28 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>183 open issues, up by 12.</li>
-<li>686 closed issues, down by 4.</li>
-<li>869 issues total, up by 8.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
-<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
-<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R57:
-2008-06-27 post-Sophia Antipolis mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>171 open issues, down by 20.</li>
-<li>690 closed issues, up by 43.</li>
-<li>861 issues total, up by 23.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li>
-<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li>
-<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li>
-<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
-<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
-<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li>
-<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
-<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R56:
-2008-05-16 pre-Sophia Antipolis mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>191 open issues, up by 24.</li>
-<li>647 closed issues, up by 1.</li>
-<li>838 issues total, up by 25.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R55:
-2008-03-14 post-Bellevue mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>167 open issues, down by 39.</li>
-<li>646 closed issues, up by 65.</li>
-<li>813 issues total, up by 26.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
-<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
-<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li>
-<li>Changed the following issues from NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li>
-<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>.</li>
-<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
-<li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li>
-<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
-<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
-<li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
-<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
-<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R54:
-2008-02-01 pre-Bellevue mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>206 open issues, up by 23.</li>
-<li>581 closed issues, up by 0.</li>
-<li>787 issues total, up by 23.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
-<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li>
-<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>.</li>
-<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li>
-<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>.</li>
-<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R53:
-2007-12-09 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>183 open issues, up by 11.</li>
-<li>581 closed issues, down by 1.</li>
-<li>764 issues total, up by 10.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
-<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li>
-<li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R52:
-2007-10-19 post-Kona mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>172 open issues, up by 4.</li>
-<li>582 closed issues, up by 27.</li>
-<li>754 issues total, up by 31.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
-<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li>
-<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
-<li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li>
-<li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li>
-<li>Changed the following issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R51:
-2007-09-09 pre-Kona mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>168 open issues, up by 15.</li>
-<li>555 closed issues, up by 0.</li>
-<li>723 issues total, up by 15.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R50:
-2007-08-05 post-Toronto mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>153 open issues, down by 5.</li>
-<li>555 closed issues, up by 17.</li>
-<li>708 issues total, up by 12.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>.</li>
-<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.</li>
-<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
-<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
-<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>.</li>
-<li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
-<li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R49:
-2007-06-23 pre-Toronto mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>158 open issues, up by 13.</li>
-<li>538 closed issues, up by 7.</li>
-<li>696 issues total, up by 20.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
-<li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>.</li>
-<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R48:
-2007-05-06 post-Oxford mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>145 open issues, down by 33.</li>
-<li>531 closed issues, up by 53.</li>
-<li>676 issues total, up by 20.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li>
-<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
-<li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li>
-<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li>
-<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
-<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
-<li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li>
-<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R47:
-2007-03-09 pre-Oxford mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>178 open issues, up by 37.</li>
-<li>478 closed issues, up by 0.</li>
-<li>656 issues total, up by 37.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
-<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
-<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R46:
-2007-01-12 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>141 open issues, up by 11.</li>
-<li>478 closed issues, down by 1.</li>
-<li>619 issues total, up by 10.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R45:
-2006-11-03 post-Portland mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>130 open issues, up by 0.</li>
-<li>479 closed issues, up by 17.</li>
-<li>609 issues total, up by 17.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a> to WP.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a> to NAD.</li>
-<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a> to Review.</li>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R44:
-2006-09-08 pre-Portland mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>130 open issues, up by 6.</li>
-<li>462 closed issues, down by 1.</li>
-<li>592 issues total, up by 5.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R43:
-2006-06-23 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>124 open issues, up by 14.</li>
-<li>463 closed issues, down by 1.</li>
-<li>587 issues total, up by 13.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li>
-<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.</li>
-</ul></li>
-</ul>
-</li>
-<li>R42:
-2006-04-21 post-Berlin mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>110 open issues, down by 16.</li>
-<li>464 closed issues, up by 24.</li>
-<li>574 issues total, up by 8.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
-<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
-<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
-</ul></li>
-</ul>
-</li>
-<li>R41:
-2006-02-24 pre-Berlin mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>126 open issues, up by 31.</li>
-<li>440 closed issues, up by 0.</li>
-<li>566 issues total, up by 31.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
-<li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
-<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R40:
-2005-12-16 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>95 open issues.</li>
-<li>440 closed issues.</li>
-<li>535 issues total.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R39:
-2005-10-14 post-Mont Tremblant mailing.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready.
-Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
-Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
-</li>
-<li>R38:
-2005-07-03 pre-Mont Tremblant mailing.
-Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
-</li>
-<li>R37:
-2005-06 mid-term mailing.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>.
-</li>
-<li>R36:
-2005-04 post-Lillehammer mailing. All issues in "ready" status except
-for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues
-previously in "DR" status were moved to "WP".
-</li>
-<li>R35:
-2005-03 pre-Lillehammer mailing.
-</li>
-<li>R34:
-2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
-</li>
-<li>R33:
-2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
-</li>
-<li>R32:
-2004-09 pre-Redmond mailing: reflects new proposed resolutions and
-new issues received after the 2004-07 mailing. Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
-</li>
-<li>R31:
-2004-07 mid-term mailing: reflects new proposed resolutions and
-new issues received after the post-Sydney mailing. Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
-</li>
-<li>R30:
-Post-Sydney mailing: reflects decisions made at the Sydney meeting.
-Voted all "Ready" issues from R29 into the working paper.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>.
-</li>
-<li>R29:
-Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
-</li>
-<li>R28:
-Post-Kona mailing: reflects decisions made at the Kona meeting.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>.
-</li>
-<li>R27:
-Pre-Kona mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
-</li>
-<li>R26:
-Post-Oxford mailing: reflects decisions made at the Oxford meeting.
-All issues in Ready status were voted into DR status. All issues in
-DR status were voted into WP status.
-</li>
-<li>R25:
-Pre-Oxford mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>.
-</li>
-<li>R24:
-Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
-meeting. All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
-moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
-at the meeting.) Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
-concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
-</li>
-<li>R23:
-Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#382">382</a>.
-Moved issues in the TC to TC status.
-</li>
-<li>R22:
-Post-Curaao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
-</li>
-<li>R21:
-Pre-Curaao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>.
-</li>
-<li>R20:
-Post-Redmond mailing; reflects actions taken in Redmond. Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a> were added since Redmond, hence
-not discussed at the meeting.
-
-All Ready issues were moved to DR status, with the exception of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
-
-Noteworthy issues discussed at Redmond include
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
-</li>
-<li>R19:
-Pre-Redmond mailing. Added new issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>.
-</li>
-<li>R18:
-Post-Copenhagen mailing; reflects actions taken in Copenhagen.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>.
-
-Changed status of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
-to DR.
-
-Changed status of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>
-to Ready.
-
-Closed issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
-as NAD.
-
-</li>
-<li>R17:
-Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
-resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>.
-</li>
-<li>R16:
-post-Toronto mailing; reflects actions taken in Toronto. Added new
-issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>. Changed status of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>. Reopened
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
-appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
-the bug in enough places.
-</li>
-<li>R15:
-pre-Toronto mailing. Added issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>. Some small HTML formatting
-changes so that we pass Weblint tests.
-</li>
-<li>R14:
-post-Tokyo II mailing; reflects committee actions taken in
-Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
-</li>
-<li>R13:
-pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.
-</li>
-<li>R12:
-pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
-of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
-</li>
-<li>R11:
-post-Kona mailing: Updated to reflect LWG and full committee actions
-in Kona (99-0048/N1224). Note changed resolution of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a>
-to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
-"closed" documents. Changed the proposed resolution of issue
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
-of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
-</li>
-<li>R10:
-pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a> to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
-</li>
-<li>R9:
-pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
-"closed" documents. (99-0030/N1206, 25 Aug 99)
-</li>
-<li>R8:
-post-Dublin mailing. Updated to reflect LWG and full committee actions
-in Dublin. (99-0016/N1193, 21 Apr 99)
-</li>
-<li>R7:
-pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
-</li>
-<li>R6:
-pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>,
-and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
-</li>
-<li>R5:
-update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>. Format revisions to prepare
-for making list public. (30 Dec 98)
-</li>
-<li>R4:
-post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
-issues corrected. (22 Oct 98)
-</li>
-<li>R3:
-post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>
-added, many issues updated to reflect LWG consensus (12 Oct 98)
-</li>
-<li>R2:
-pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added,
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
-</li>
-<li>R1:
-Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code
-format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
-</li>
-</ul>
-
-<h2>Closed Issues</h2>
-<hr>
-<h3><a name="2"></a>2. Auto_ptr conversions effects incorrect</h3>
-<p><b>Section:</b> D.9.1.3 [auto.ptr.conv] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1997-12-04</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Paragraph 1 in "Effects", says "Calls
-p-&gt;release()" where it clearly must be "Calls
-p.release()". (As it is, it seems to require using
-auto_ptr&lt;&gt;::operator-&gt; to refer to X::release, assuming that
-exists.)</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 20.5.4.3 [meta.unary.prop] paragraph 1 Effects from
-"Calls p-&gt;release()" to "Calls p.release()".</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Not a defect: the proposed change is already found in the standard.
-[Originally classified as a defect, later reclassified.]</p>
-
-
-
-
-
-<hr>
-<h3><a name="4"></a>4. Basic_string size_type and difference_type should be implementation defined</h3>
-<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In Morristown we changed the size_type and difference_type typedefs
-for all the other containers to implementation defined with a
-reference to 23.1 [container.requirements]. This should probably also have been
-done for strings. </p>
-
-
-<p><b>Rationale:</b></p>
-<p>Not a defect. [Originally classified as a defect, later
-reclassified.] basic_string, unlike the other standard library
-template containers, is severely constrained by its use of
-char_traits. Those types are dictated by the traits class, and are far
-from implementation defined.</p>
-
-
-
-
-
-<hr>
-<h3><a name="6"></a>6. File position not an offset unimplementable</h3>
-<p><b>Section:</b> 27.4.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Table 88, in I/O, is too strict; it's unimplementable on systems
-where a file position isn't just an offset. It also never says just
-what fpos&lt;&gt; is really supposed to be. [Here's my summary, which
-Jerry agrees is more or less accurate. "I think I now know what
-the class really is, at this point: it's a magic cookie that
-encapsulates an mbstate_t and a file position (possibly represented as
-an fpos_t), it has syntactic support for pointer-like arithmetic, and
-implementors are required to have real, not just syntactic, support
-for arithmetic." This isn't standardese, of course.] </p>
-
-
-<p><b>Rationale:</b></p>
-<p>Not a defect. The LWG believes that the Standard is already clear,
-and that the above summary is what the Standard in effect says.</p>
-
-
-
-
-
-<hr>
-<h3><a name="10"></a>10. Codecvt&lt;&gt;::do unclear</h3>
-<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a></p>
-<p><b>Discussion:</b></p>
-<p>Section 22.2.1.5.2 says that codecvt&lt;&gt;::do_in and do_out
-should return the value noconv if "no conversion was
-needed". However, I don't see anything anywhere that defines what
-it means for a conversion to be needed or not needed. I can think of
-several circumstances where one might plausibly think that a
-conversion is not "needed", but I don't know which one is
-intended here. </p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="12"></a>12. Way objects hold allocators unclear</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1998-02-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>I couldn't find a statement in the standard saying whether the allocator object held by
-a container is held as a copy of the constructor argument or whether a pointer of
-reference is maintained internal. There is an according statement for compare objects and
-how they are maintained by the associative containers, but I couldn't find anything
-regarding allocators. </p>
-
-<p>Did I overlook it? Is it an open issue or known defect? Or is it deliberately left
-unspecified? </p>
-
-
-<p><b>Rationale:</b></p>
-<p>Not a defect. The LWG believes that the Standard is already
-clear.&nbsp; See 23.1 [container.requirements], paragraph 8.</p>
-
-
-
-
-
-<hr>
-<h3><a name="43"></a>43. Locale table correction</h3>
-<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1998-06-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a></p>
-<p><b>Discussion:</b></p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="45"></a>45. Stringstreams read/write pointers initial position unclear</h3>
-<p><b>Section:</b> 27.7.3 [ostringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matthias Mueller <b>Date:</b> 1998-05-27</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In a comp.lang.c++.moderated Matthias Mueller wrote:</p>
-
-<p>"We are not sure how to interpret the CD2 (see 27.2
-[iostream.forward], 27.7.3.1 [ostringstream.cons], 27.7.1.1
-[stringbuf.cons])
-with respect to the question as to what the correct initial positions
-of the write and&nbsp; read pointers of a stringstream should
-be."</p>
-
-<p>"Is it the same to output two strings or to initialize the stringstream with the
-first and to output the second?"</p>
-
-<p><i>[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and
-Jerry Schwarz have all offered opinions; see reflector messages
-lib-6518, 6519, 6520, 6521, 6523, 6524.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes the Standard is correct as written. The behavior
-of stringstreams is consistent with fstreams, and there is a
-constructor which can be used to obtain the desired effect. This
-behavior is known to be different from strstreams.</p>
-
-
-
-
-
-<hr>
-<h3><a name="58"></a>58. Extracting a char from a wide-oriented stream</h3>
-<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>27.6.1.2.3 has member functions for extraction of signed char and
-unsigned char, both singly and as strings. However, it doesn't say
-what it means to extract a <tt>char</tt> from a
-<tt>basic_streambuf&lt;charT, Traits&gt;</tt>. </p>
-
-<p>basic_streambuf, after all, has no members to extract a char, so
-basic_istream must somehow convert from charT to signed char or
-unsigned char. The standard doesn't say how it is to perform that
-conversion. </p>
-
-
-<p><b>Rationale:</b></p>
-<p>The Standard is correct as written. There is no such extractor and
-this is the intent of the LWG.</p>
-
-
-
-
-<hr>
-<h3><a name="65"></a>65. Underspecification of strstreambuf::seekoff</h3>
-<p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The standard says how this member function affects the current
-stream position. (<tt>gptr</tt> or <tt>pptr</tt>) However, it does not
-say how this member function affects the beginning and end of the
-get/put area. </p>
-
-<p>This is an issue when seekoff is used to position the get pointer
-beyond the end of the current read area. (Which is legal. This is
-implicit in the definition of <i>seekhigh</i> in D.7.1, paragraph 4.)
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG agrees that seekoff() is underspecified, but does not wish
-to invest effort in this deprecated feature.</p>
-
-
-
-
-
-<hr>
-<h3><a name="67"></a>67. Setw useless for strings</h3>
-<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-07-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a></p>
-<p><b>Discussion:</b></p>
-<p>In a comp.std.c++ posting Michel Michaud wrote: What
-should be output by: </p>
-
-<pre> string text("Hello");
- cout &lt;&lt; '[' &lt;&lt; setw(10) &lt;&lt; right &lt;&lt; text &lt;&lt; ']';
-</pre>
-
-<p>Shouldn't it be:</p>
-
-<pre> [ Hello]</pre>
-
-<p>Another person replied: Actually, according to the FDIS, the width
-of the field should be the minimum of width and the length of the
-string, so the output shouldn't have any padding. I think that this is
-a typo, however, and that what is wanted is the maximum of the
-two. (As written, setw is useless for strings. If that had been the
-intent, one wouldn't expect them to have mentioned using its value.)
-</p>
-
-<p>It's worth pointing out that this is a recent correction anyway;
-IIRC, earlier versions of the draft forgot to mention formatting
-parameters whatsoever.</p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="72"></a>72. Do_convert phantom member function</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a></p>
-<p><b>Discussion:</b></p>
-<p>In 22.2.1.4 [locale.codecvt] par 3, and in 22.2.1.4.2 [locale.codecvt.virtuals] par 8, a nonexistent member function
-"do_convert" is mentioned. This member was replaced with
-"do_in" and "do_out", the proper referents in the
-contexts above.</p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="73"></a>73. <tt>is_open</tt> should be const</h3>
-<p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Classes <tt>basic_ifstream</tt>, <tt>basic_ofstream</tt>, and
-<tt>basic_fstream</tt> all have a member function <tt>is_open</tt>. It
-should be a <tt>const</tt> member function, since it does nothing but
-call one of <tt>basic_filebuf</tt>'s const member functions. </p>
-
-
-<p><b>Rationale:</b></p>
-<p>Not a defect. This is a deliberate feature; const streams would be
-meaningless.</p>
-
-
-
-
-<hr>
-<h3><a name="77"></a>77. Valarray operator[] const returning value</h3>
-<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Levente Farkas <b>Date:</b> 1998-09-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a></p>
-<p><b>Discussion:</b></p>
-<p>valarray:<br>
-<br>
-&nbsp;&nbsp;&nbsp; <tt>T operator[] (size_t) const;</tt><br>
-<br>
-why not <br>
-<br>
-&nbsp;&nbsp;&nbsp; <tt>const T&amp; operator[] (size_t) const;</tt><br>
-<br>
-as in vector ???<br>
-<br>
-One can't copy even from a const valarray eg:<br>
-<br>
-&nbsp;&nbsp;&nbsp; <tt>memcpy(ptr, &amp;v[0], v.size() * sizeof(double));<br>
-</tt><br>
-[I] find this bug in valarray is very difficult.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes that the interface was deliberately designed that
-way. That is what valarray was designed to do; that's where the
-"value array" name comes from. LWG members further comment
-that "we don't want valarray to be a full STL container."
-26.5.2.3 [valarray.access] specifies properties that indicate "an
-absence of aliasing" for non-constant arrays; this allows
-optimizations, including special hardware optimizations, that are not
-otherwise possible. </p>
-
-
-
-
-
-<hr>
-<h3><a name="81"></a>81. Wrong declaration of slice operations</h3>
-<p><b>Section:</b> 26.5.5 [template.slice.array], 26.5.7 [template.gslice.array], 26.5.8 [template.mask.array], 26.5.9 [template.indirect.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.slice.array">issues</a> in [template.slice.array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Isn't the definition of copy constructor and assignment operators wrong?
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Instead of</p>
-
-<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array(const slice_array&amp;);
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; slice_array&amp; operator=(const slice_array&amp;);</pre>
-
-<p>IMHO they have to be</p>
-
-<pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array(const slice_array&lt;T&gt;&amp;);
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;slice_array&amp; operator=(const slice_array&lt;T&gt;&amp;);</pre>
-
-<p>Same for gslice_array. </p>
-
-
-<p><b>Rationale:</b></p>
-<p>Not a defect. The Standard is correct as written. </p>
-
-
-
-
-<hr>
-<h3><a name="82"></a>82. Missing constant for set elements</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Paragraph 5 specifies:</p>
-
-<blockquote><p>
-For set and multiset the value type is the same as the key type. For
-map and multimap it is equal to pair&lt;const Key, T&gt;.
-</p></blockquote>
-
-<p>Strictly speaking, this is not correct because for set and multiset
-the value type is the same as the <b>constant</b> key type.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Not a defect. The Standard is correct as written; it uses a
-different mechanism (const &amp;) for <tt>set</tt> and
-<tt>multiset</tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for a related
-issue.</p>
-
-
-
-
-<hr>
-<h3><a name="84"></a>84. Ambiguity with string::insert()</h3>
-<p><b>Section:</b> 21.3.5 [string.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>If I try</p>
-<pre> s.insert(0,1,' ');</pre>
-
-<p>&nbsp; I get an nasty ambiguity. It might be</p>
-<pre> s.insert((size_type)0,(size_type)1,(charT)' ');</pre>
-
-<p>which inserts 1 space character at position 0, or</p>
-<pre> s.insert((char*)0,(size_type)1,(charT)' ')</pre>
-
-<p>which inserts 1 space character at iterator/address 0 (bingo!), or</p>
-<pre> s.insert((char*)0, (InputIterator)1, (InputIterator)' ')</pre>
-
-<p>which normally inserts characters from iterator 1 to iterator '
-'. But according to 23.1.1.9 (the "do the right thing" fix)
-it is equivalent to the second. However, it is still ambiguous,
-because of course I mean the first!</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Not a defect. The LWG believes this is a "genetic
-misfortune" inherent in the design of string and thus not a
-defect in the Standard as such .</p>
-
-
-
-
-<hr>
-<h3><a name="85"></a>85. String char types</h3>
-<p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The standard seems not to require that charT is equivalent to
-traits::char_type. So, what happens if charT is not equivalent to
-traits::char_type?</p>
-
-
-<p><b>Rationale:</b></p>
-<p>There is already wording in 21.1 [char.traits] paragraph 3 that
-requires them to be the same.</p>
-
-
-
-
-<hr>
-<h3><a name="87"></a>87. Error in description of string::compare()</h3>
-<p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a></p>
-<p><b>Discussion:</b></p>
-<p>The following compare() description is obviously a bug:</p>
-
-<pre>int compare(size_type pos, size_type n1,
- charT *s, size_type n2 = npos) const;
-</pre>
-
-<p>because without passing n2 it should compare up to the end of the
-string instead of comparing npos characters (which throws an
-exception) </p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="88"></a>88. Inconsistency between string::insert() and string::append()</h3>
-<p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.2 [string::append] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Why does </p>
-<pre> template&lt;class InputIterator&gt;
- basic_string&amp; append(InputIterator first, InputIterator last);</pre>
-
-<p>return a string, while</p>
-<pre> template&lt;class InputIterator&gt;
- void insert(iterator p, InputIterator first, InputIterator last);</pre>
-
-<p>returns nothing ?</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes this stylistic inconsistency is not sufficiently
-serious to constitute a defect.</p>
-
-
-
-
-<hr>
-<h3><a name="89"></a>89. Missing throw specification for string::insert() and string::replace()</h3>
-<p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a></p>
-<p><b>Discussion:</b></p>
-<p>All insert() and replace() members for strings with an iterator as
-first argument lack a throw specification. The throw
-specification should probably be: length_error if size exceeds
-maximum. </p>
-
-
-<p><b>Rationale:</b></p>
-<p>Considered a duplicate because it will be solved by the resolution
-of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
-
-
-
-
-
-<hr>
-<h3><a name="93"></a>93. Incomplete Valarray Subset Definitions</h3>
-<p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>You can easily create subsets, but you can't easily combine them
-with other subsets. Unfortunately, you almost always needs an
-explicit type conversion to valarray. This is because the standard
-does not specify that valarray subsets provide the same operations as
-valarrays. </p>
-
-<p>For example, to multiply two subsets and assign the result to a third subset, you can't
-write the following:</p>
-
-<pre>va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];</pre>
-
-<p>Instead, you have to code as follows:</p>
-
-<pre>va[slice(0,4,3)] = static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(1,4,3)]) *
- static_cast&lt;valarray&lt;double&gt; &gt;(va[slice(2,4,3)]);</pre>
-
-<p>This is tedious and error-prone. Even worse, it costs performance because each cast
-creates a temporary objects, which could be avoided without the cast. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Extend all valarray subset types so that they offer all valarray operations.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This is not a defect in the Standard; it is a request for an extension.</p>
-
-
-
-
-<hr>
-<h3><a name="94"></a>94. May library implementors add template parameters to Standard Library classes?</h3>
-<p><b>Section:</b> 17.4.4 [conforming] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Is it a permitted extension for library implementors to add template parameters to
-standard library classes, provided that those extra parameters have defaults? For example,
-instead of defining <tt>template &lt;class T, class Alloc = allocator&lt;T&gt; &gt; class
-vector;</tt> defining it as <tt>template &lt;class T, class Alloc = allocator&lt;T&gt;,
-int N = 1&gt; class vector;</tt> </p>
-
-<p>The standard may well already allow this (I can't think of any way that this extension
-could break a conforming program, considering that users are not permitted to
-forward-declare standard library components), but it ought to be explicitly permitted or
-forbidden. </p>
-
-<p>comment from Steve Cleary via comp.std.c++:</p>
-<blockquote>
-<p>I disagree [with the proposed resolution] for the following reason:
-consider user library code with template template parameters. For
-example, a user library object may be templated on the type of
-underlying sequence storage to use (deque/list/vector), since these
-classes all take the same number and type of template parameters; this
-would allow the user to determine the performance tradeoffs of the
-user library object. A similar example is a user library object
-templated on the type of underlying set storage (set/multiset) or map
-storage (map/multimap), which would allow users to change (within
-reason) the semantic meanings of operations on that object.</p>
-<p>I think that additional template parameters should be forbidden in
-the Standard classes. Library writers don't lose any expressive power,
-and can still offer extensions because additional template parameters
-may be provided by a non-Standard implementation class:</p>
-<pre>
- template &lt;class T, class Allocator = allocator&lt;T&gt;, int N = 1&gt;
- class __vector
- { ... };
- template &lt;class T, class Allocator = allocator&lt;T&gt; &gt;
- class vector: public __vector&lt;T, Allocator&gt;
- { ... };
-</pre>
-
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.9 [res.on.exception.handling]:</p>
-
-<blockquote>
- <p>17.4.4.9 Template Parameters</p> <p>A specialization of a
- template class described in the C++ Standard Library behaves the
- same as if the implementation declares no additional template
- parameters.</p> <p>Footnote: Additional template parameters with
- default values are thus permitted.</p>
-</blockquote>
-
-<p>Add "template parameters" to the list of subclauses at
-the end of 17.4.4 [conforming] paragraph 1.</p>
-
-<p><i>[Kona: The LWG agreed the standard needs clarification. After
-discussion with John Spicer, it seems added template parameters can be
-detected by a program using template-template parameters. A straw vote
-- "should implementors be allowed to add template
-parameters?" found no consensus ; 5 - yes, 7 - no.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-There is no ambiguity; the standard is clear as written. Library
-implementors are not permitted to add template parameters to standard
-library classes. This does not fall under the "as if" rule,
-so it would be permitted only if the standard gave explicit license
-for implementors to do this. This would require a change in the
-standard.
-</p>
-
-<p>
-The LWG decided against making this change, because it would break
-user code involving template template parameters or specializations
-of standard library class templates.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="95"></a>95. Members added by the implementation</h3>
-<p><b>Section:</b> 17.4.4.4 [member.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual
-members a base class and break user derived classes.</p>
-
-<p>Example: </p>
-
-<blockquote>
- <pre>// implementation code:
-struct _Base { // _Base is in the implementer namespace
- virtual void foo ();
-};
-class vector : _Base // deriving from a class is allowed
-{ ... };
-
-// user code:
-class vector_checking : public vector
-{
- void foo (); // don't want to override _Base::foo () as the
- // user doesn't know about _Base::foo ()
-};</pre>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Clarify the wording to make the example illegal.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This is not a defect in the Standard.&nbsp; The example is already
-illegal.&nbsp; See 17.4.4.4 [member.functions] paragraph 2.</p>
-
-
-
-
-<hr>
-<h3><a name="97"></a>97. Insert inconsistent definition</h3>
-<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p><tt>insert(iterator, const value_type&amp;)</tt> is defined both on
-sequences and on set, with unrelated semantics: insert here (in
-sequences), and insert with hint (in associative containers). They
-should have different names (B.S. says: do not abuse overloading).</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This is not a defect in the Standard. It is a genetic misfortune of
-the design, for better or for worse.</p>
-
-
-
-
-<hr>
-<h3><a name="99"></a>99. Reverse_iterator comparisons completely wrong</h3>
-<p><b>Section:</b> 24.4.1.3.13 [reverse.iter.op==] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The &lt;, &gt;, &lt;=, &gt;= comparison operator are wrong: they
-return the opposite of what they should.</p>
-
-<p>Note: same problem in CD2, these were not even defined in CD1. SGI
-STL code is correct; this problem is known since the Morristown
-meeting but there it was too late</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This is not a defect in the Standard. A careful reading shows the Standard is correct
-as written. A review of several implementations show that they implement
-exactly what the Standard says.</p>
-
-
-
-
-<hr>
-<h3><a name="100"></a>100. Insert iterators/ostream_iterators overconstrained</h3>
-<p><b>Section:</b> 24.4.2 [insert.iterators], 24.5.4 [ostreambuf.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Overspecified For an insert iterator it, the expression *it is
-required to return a reference to it. This is a simple possible
-implementation, but as the SGI STL documentation says, not the only
-one, and the user should not assume that this is the case.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes this causes no harm and is not a defect in the
-standard. The only example anyone could come up with caused some
-incorrect code to work, rather than the other way around.</p>
-
-
-
-
-
-<hr>
-<h3><a name="101"></a>101. No way to free storage for vector and deque</h3>
-<p><b>Section:</b> 23.2.6 [vector], 23.2.1 [array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Reserve can not free storage, unlike string::reserve</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This is not a defect in the Standard. The LWG has considered this
-issue in the past and sees no need to change the Standard. Deque has
-no reserve() member function. For vector, shrink-to-fit can be
-expressed in a single line of code (where <tt>v</tt> is
-<tt>vector&lt;T&gt;</tt>):
-</p>
-
-<blockquote>
- <p><tt>vector&lt;T&gt;(v).swap(v);&nbsp; // shrink-to-fit v</tt></p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="102"></a>102. Bug in insert range in associative containers</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a></p>
-<p><b>Discussion:</b></p>
-<p>Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems
-impossible to implement, as it means that if [i, j) = [x], insert in an associative
-container is O(1)!</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>N+log (size()) if [i,j) is sorted according to value_comp()</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>.</p>
-
-
-
-
-
-<hr>
-<h3><a name="104"></a>104. Description of basic_string::operator[] is unclear</h3>
-<p><b>Section:</b> 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.capacity">issues</a> in [string.capacity].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>It is not clear that undefined behavior applies when pos == size ()
-for the non const version.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Rewrite as: Otherwise, if pos &gt; size () or pos == size () and
-the non-const version is used, then the behavior is undefined.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The Standard is correct. The proposed resolution already appears in
-the Standard.</p>
-
-
-
-
-<hr>
-<h3><a name="105"></a>105. fstream ctors argument types desired</h3>
-<p><b>Section:</b> 27.8 [file.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a></p>
-<p><b>Discussion:</b></p>
-
-
-<p>fstream ctors take a const char* instead of string.<br>
-fstream ctors can't take wchar_t</p>
-
-<p>An extension to add a const wchar_t* to fstream would make the
-implementation non conforming.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This is not a defect in the Standard. It might be an
-interesting extension for the next Standard. </p>
-
-
-
-
-<hr>
-<h3><a name="107"></a>107. Valarray constructor is strange</h3>
-<p><b>Section:</b> 26.5.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.valarray">issues</a> in [template.valarray].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The order of the arguments is (elem, size) instead of the normal
-(size, elem) in the rest of the library. Since elem often has an
-integral or floating point type, both types are convertible to each
-other and reversing them leads to a well formed program.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Inverting the arguments could silently break programs. Introduce
-the two signatures (const T&amp;, size_t) and (size_t, const T&amp;),
-but make the one we do not want private so errors result in a
-diagnosed access violation. This technique can also be applied to STL
-containers.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes that while the order of arguments is unfortunate,
-it does not constitute a defect in the standard. The LWG believes that
-the proposed solution will not work for valarray&lt;size_t&gt; and
-perhaps other cases.</p>
-
-
-
-
-<hr>
-<h3><a name="111"></a>111. istreambuf_iterator::equal overspecified, inefficient</h3>
-<p><b>Section:</b> 24.5.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-10-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The member istreambuf_iterator&lt;&gt;::equal is specified to be
-unnecessarily inefficient. While this does not affect the efficiency
-of conforming implementations of iostreams, because they can
-"reach into" the iterators and bypass this function, it does
-affect users who use istreambuf_iterators. </p>
-
-<p>The inefficiency results from a too-scrupulous definition, which
-requires a "true" result if neither iterator is at eof. In
-practice these iterators can only usefully be compared with the
-"eof" value, so the extra test implied provides no benefit,
-but slows down users' code. </p>
-
-<p>The solution is to weaken the requirement on the function to return
-true only if both iterators are at eof. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace 24.5.3.5 [istreambuf.iterator::equal],
-paragraph 1, </p>
-
-<blockquote>
- <p>-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at
- end-of-stream, regardless of what streambuf object they use. </p>
-</blockquote>
-
-<p>with</p>
-
-<blockquote>
- <p>-1- Returns: true if and only if both iterators are at
- end-of-stream, regardless of what streambuf object they use. </p>
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>It is not clear that this is a genuine defect. Additionally, the
-LWG was reluctant to make a change that would result in
-operator== not being a equivalence relation. One consequence of
-this change is that an algorithm that's passed the range [i, i)
-would no longer treat it as an empty range.</p>
-
-
-
-
-
-<hr>
-<h3><a name="113"></a>113. Missing/extra iostream sync semantics</h3>
-<p><b>Section:</b> 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-10-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream">issues</a> in [istream].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3,
-paragraph 36. </p>
-
-<p>Following the chain of definitions, I find that the various sync functions have defined
-semantics for output streams, but no semantics for input streams. On the other hand,
-basic_ostream has no sync function. </p>
-
-<p>The sync function should at minimum be added to basic_ostream, for internal
-consistency. </p>
-
-<p>A larger question is whether sync should have assigned semantics for input streams. </p>
-
-<p>Classic iostreams said streambuf::sync flushes pending output and attempts to return
-unread input characters to the source. It is a protected member function. The filebuf
-version (which is public) has that behavior (it backs up the read pointer). Class
-strstreambuf does not override streambuf::sync, and so sync can't be called on a
-strstream. </p>
-
-<p>If we can add corresponding semantics to the various sync functions, we should. If not,
-we should remove sync from basic_istream.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>A sync function is not needed in basic_ostream because the flush function provides the
-desired functionality.</p>
-
-<p>As for the other points, the LWG finds the standard correct as written.</p>
-
-
-
-
-
-<hr>
-<h3><a name="116"></a>116. bitset cannot be constructed with a const char*</h3>
-<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-11-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a></p>
-<p><b>Discussion:</b></p>
-
-
-
-<p>The following code does not compile with the EDG compiler:</p>
-
-<blockquote>
- <pre>#include &lt;bitset&gt;
-using namespace std;
-bitset&lt;32&gt; b("111111111");</pre>
-</blockquote>
-
-<p>If you cast the ctor argument to a string, i.e.:</p>
-
-<blockquote>
- <pre>bitset&lt;32&gt; b(string("111111111"));</pre>
-</blockquote>
-
-<p>then it will compile. The reason is that bitset has the following templatized
-constructor:</p>
-
-<blockquote>
- <pre>template &lt;class charT, class traits, class Allocator&gt;
-explicit bitset (const basic_string&lt;charT, traits, Allocator&gt;&amp; str, ...);</pre>
-</blockquote>
-
-<p>According to the compiler vendor, Steve Adamcyk at EDG, the user
-cannot pass this template constructor a <tt>const char*</tt> and
-expect a conversion to <tt>basic_string</tt>. The reason is
-"When you have a template constructor, it can get used in
-contexts where type deduction can be done. Type deduction basically
-comes up with exact matches, not ones involving conversions."
-</p>
-
-<p>I don't think the intention when this constructor became
-templatized was for construction from a <tt>const char*</tt> to no
-longer work.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add to 23.3.5 [template.bitset] a bitset constructor declaration</p>
-
-<blockquote>
- <pre>explicit bitset(const char*);</pre>
-</blockquote>
-
-<p>and in Section 23.3.5.1 [bitset.cons] add:</p>
-
-<blockquote>
- <pre>explicit bitset(const char* str);</pre>
- <p>Effects: <br>
- &nbsp;&nbsp;&nbsp; Calls <tt>bitset((string) str, 0, string::npos);</tt></p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>Although the problem is real, the standard is designed that way so
-it is not a defect. Education is the immediate workaround. A future
-standard may wish to consider the Proposed Resolution as an
-extension.</p>
-
-
-
-
-
-<hr>
-<h3><a name="121"></a>121. Detailed definition for ctype&lt;wchar_t&gt; specialization</h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Section 22.1.1.1.1 has the following listed in Table 51: ctype&lt;char&gt; ,
-ctype&lt;wchar_t&gt;. </p>
-
-<p>Also Section 22.2.1.1 [locale.ctype] says: </p>
-
-<blockquote>
- <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype&lt;char&gt; and
- ctype&lt;wchar_t&gt; , implement character classing appropriate to the implementation's
- native character set. </p>
-</blockquote>
-
-<p>However, Section 22.2.1.3 [facet.ctype.special]
-only has a detailed description of the ctype&lt;char&gt; specialization, not the
-ctype&lt;wchar_t&gt; specialization. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add the ctype&lt;wchar_t&gt; detailed class description to Section
-22.2.1.3 [facet.ctype.special]. </p>
-
-
-<p><b>Rationale:</b></p>
-<p>Specialization for wchar_t is not needed since the default is acceptable.</p>
-
-
-
-
-
-<hr>
-<h3><a name="131"></a>131. list::splice throws nothing</h3>
-<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>What happens if a splice operation causes the size() of a list to grow
-beyond max_size()?</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Size() cannot grow beyond max_size().&nbsp; </p>
-
-
-
-
-
-<hr>
-<h3><a name="135"></a>135. basic_iostream doubly initialized</h3>
-<p><b>Section:</b> 27.6.1.5.1 [iostream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>-1- Effects Constructs an object of class basic_iostream, assigning
-initial values to the base classes by calling
-basic_istream&lt;charT,traits&gt;(sb) (lib.istream) and
-basic_ostream&lt;charT,traits&gt;(sb) (lib.ostream)</p>
-
-<p>The called for basic_istream and basic_ostream constructors call
-init(sb). This means that the basic_iostream's virtual base class is
-initialized twice.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 27.6.1.5.1, paragraph 1 to:</p>
-
-<p>-1- Effects Constructs an object of class basic_iostream, assigning
-initial values to the base classes by calling
-basic_istream&lt;charT,traits&gt;(sb) (lib.istream).</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG agreed that the <tt> init()</tt> function is called
-twice, but said that this is harmless and so not a defect in the
-standard.</p>
-
-
-
-
-<hr>
-<h3><a name="138"></a>138. Class ctype_byname&lt;char&gt; redundant and misleading</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-03-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Section 22.2.1.4 [locale.codecvt] specifies that
-ctype_byname&lt;char&gt; must be a specialization of the ctype_byname
-template.</p>
-
-<p>It is common practice in the standard that specializations of class templates are only
-mentioned where the interface of the specialization deviates from the interface of the
-template that it is a specialization of. Otherwise, the fact whether or not a required
-instantiation is an actual instantiation or a specialization is left open as an
-implementation detail. </p>
-
-<p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The
-fact, that ctype_byname&lt;char&gt; is specified as a specialization suggests that there
-must be something "special" about it, but it has the exact same interface as the
-ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best
-redundant, at worst misleading - unless I am missing anything. </p>
-
-<p>Naturally, an implementation will most likely implement ctype_byname&lt;char&gt; as a
-specialization, because the base class ctype&lt;char&gt; is a specialization with an
-interface different from the ctype template, but that's an implementation detail and need
-not be mentioned in the standard. </p>
-
-
-<p><b>Rationale:</b></p>
-<p> The standard as written is mildly misleading, but the correct fix
-is to deal with the underlying problem in the ctype_byname base class,
-not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
-
-
-
-
-<hr>
-<h3><a name="140"></a>140. map&lt;Key, T&gt;::value_type does not satisfy the assignable requirement</h3>
-<p><b>Section:</b> 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Mark Mitchell <b>Date:</b> 1999-04-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<blockquote>
- <p>23.1 [container.requirements]<br>
- <br>
- expression&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return type
- &nbsp;&nbsp;&nbsp;&nbsp; pre/post-condition<br>
- -------------&nbsp;&nbsp;&nbsp;&nbsp; ----------- &nbsp;&nbsp;&nbsp;&nbsp;
- -------------------<br>
- X::value_type&nbsp;&nbsp;&nbsp; T
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- T is assignable<br>
- <br>
- 23.3.1 [map]<br>
- <br>
- A map satisfies all the requirements of a container.<br>
- <br>
- For a map&lt;Key, T&gt; ... the value_type is pair&lt;const Key, T&gt;.</p>
-</blockquote>
-
-<p>There's a contradiction here. In particular, `pair&lt;const Key,
-T&gt;' is not assignable; the `const Key' cannot be assigned
-to. So,&nbsp; map&lt;Key, T&gt;::value_type does not satisfy the
-assignable requirement imposed by a container.</p>
-
-<p><i>[See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for the slightly related issue of
-modification of set keys.]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes that the standard is inconsistent, but that this
-is a design problem rather than a strict defect. May wish to
-reconsider for the next standard.</p>
-
-
-
-
-<hr>
-<h3><a name="143"></a>143. C .h header wording unclear</h3>
-<p><b>Section:</b> D.5 [depr.c.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Christophe de Dinechin <b>Date:</b> 1999-05-04</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>[depr.c.headers] paragraph 2 reads:</p>
-
-<blockquote>
-
-<p>Each C header, whose name has the form name.h, behaves as if each
-name placed in the Standard library namespace by the corresponding
-cname header is also placed within the namespace scope of the
-namespace std and is followed by an explicit using-declaration
-(_namespace.udecl_)</p>
-
-</blockquote>
-
-<p>I think it should mention the global name space somewhere...&nbsp;
-Currently, it indicates that name placed in std is also placed in
-std...</p>
-
-<p>I don't know what is the correct wording. For instance, if struct
-tm is defined in time.h, ctime declares std::tm. However, the current
-wording seems ambiguous regarding which of the following would occur
-for use of both ctime and time.h:</p>
-
-<blockquote>
- <pre>// version 1:
-namespace std {
- struct tm { ... };
-}
-using std::tm;
-
-// version 2:
-struct tm { ... };
-namespace std {
- using ::tm;
-}
-
-// version 3:
-struct tm { ... };
-namespace std {
- struct tm { ... };
-}</pre>
-</blockquote>
-
-<p>I think version 1 is intended.</p>
-
-<p><i>[Kona: The LWG agreed that the wording is not clear. It also
-agreed that version 1 is intended, version 2 is not equivalent to
-version 1, and version 3 is clearly not intended. The example below
-was constructed by Nathan Myers to illustrate why version 2 is not
-equivalent to version 1.</i></p>
-
-<p><i>Although not equivalent, the LWG is unsure if (2) is enough of
-a problem to be prohibited. Points discussed in favor of allowing
-(2):</i></p>
-
-<blockquote>
- <ul>
- <li><i>It may be a convenience to implementors.</i></li>
- <li><i>The only cases that fail are structs, of which the C library
- contains only a few.</i></li>
- </ul>
-</blockquote>
-
-<p><i>]</i></p>
-
-<p><b>Example:</b></p>
-
-<blockquote>
-
-<pre>#include &lt;time.h&gt;
-#include &lt;utility&gt;
-
-int main() {
- std::tm * t;
- make_pair( t, t ); // okay with version 1 due to Koenig lookup
- // fails with version 2; make_pair not found
- return 0;
-}</pre>
-
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Replace D.5 [depr.c.headers] paragraph 2 with:</p>
-
-<blockquote>
-
-<p> Each C header, whose name has the form name.h, behaves as if each
-name placed in the Standard library namespace by the corresponding
-cname header is also placed within the namespace scope of the
-namespace std by name.h and is followed by an explicit
-using-declaration (_namespace.udecl_) in global scope.</p>
-
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p> The current wording in the standard is the result of a difficult
-compromise that averted delay of the standard. Based on discussions
-in Tokyo it is clear that there is no still no consensus on stricter
-wording, so the issue has been closed. It is suggested that users not
-write code that depends on Koenig lookup of C library functions.</p>
-
-
-
-
-<hr>
-<h3><a name="145"></a>145. adjustfield lacks default value</h3>
-<p><b>Section:</b> 27.4.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-05-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>There is no initial value for the adjustfield defined, although
-many people believe that the default adjustment were right. This is a
-common misunderstanding. The standard only defines that, if no
-adjustment is specified, all the predefined inserters must add fill
-characters before the actual value, which is "as if" the
-right flag were set. The flag itself need not be set.</p>
-
-<p>When you implement a user-defined inserter you cannot rely on right
-being the default setting for the adjustfield. Instead, you must be
-prepared to find none of the flags set and must keep in mind that in
-this case you should make your inserter behave "as if" the
-right flag were set. This is surprising to many people and complicates
-matters more than necessary.</p>
-
-<p>Unless there is a good reason why the adjustfield should not be
-initialized I would suggest to give it the default value that
-everybody expects anyway.</p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>This is not a defect. It is deliberate that the default is no bits
-set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 [facet.num.put.virtuals] paragraph 19, Table 61 - Fill padding.</p>
-
-
-
-
-<hr>
-<h3><a name="149"></a>149. Insert should return iterator to first element inserted</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-06-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Suppose that c and c1 are sequential containers and i is an
-iterator that refers to an element of c. Then I can insert a copy of
-c1's elements into c ahead of element i by executing </p>
-
-<blockquote>
-
-<pre>c.insert(i, c1.begin(), c1.end());</pre>
-
-</blockquote>
-
-<p>If c is a vector, it is fairly easy for me to find out where the
-newly inserted elements are, even though i is now invalid: </p>
-
-<blockquote>
-
-<pre>size_t i_loc = i - c.begin();
-c.insert(i, c1.begin(), c1.end());</pre>
-
-</blockquote>
-
-<p>and now the first inserted element is at c.begin()+i_loc and one
-past the last is at c.begin()+i_loc+c1.size().<br>
-<br>
-But what if c is a list? I can still find the location of one past the
-last inserted element, because i is still valid. To find the location
-of the first inserted element, though, I must execute something like </p>
-
-<blockquote>
-
-<pre>for (size_t n = c1.size(); n; --n)
- --i;</pre>
-
-</blockquote>
-
-<p>because i is now no longer a random-access iterator.<br>
-<br>
-Alternatively, I might write something like </p>
-
-<blockquote>
-
-<pre>bool first = i == c.begin();
-list&lt;T&gt;::iterator j = i;
-if (!first) --j;
-c.insert(i, c1.begin(), c1.end());
-if (first)
- j = c.begin();
-else
- ++j;</pre>
-
-</blockquote>
-
-<p>which, although wretched, requires less overhead.<br>
-<br>
-But I think the right solution is to change the definition of insert
-so that instead of returning void, it returns an iterator that refers
-to the first element inserted, if any, and otherwise is a copy of its
-first argument.&nbsp; </p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes this was an intentional design decision and so is
-not a defect. It may be worth revisiting for the next standard.</p>
-
-
-
-
-<hr>
-<h3><a name="157"></a>157. Meaningless error handling for <tt>pword()</tt> and <tt>iword()</tt></h3>
-<p><b>Section:</b> 27.4.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a></p>
-<p><b>Discussion:</b></p>
-<p>According to paragraphs 2 and 4 of 27.4.2.5 [ios.base.storage], the
-functions <tt>iword()</tt> and <tt>pword()</tt> "set the
-<tt>badbit</tt> (which might throw an exception)" on
-failure. ... but what does it mean for <tt>ios_base</tt> to set the
-<tt>badbit</tt>? The state facilities of the IOStream library are
-defined in <tt>basic_ios</tt>, a derived class! It would be possible
-to attempt a down cast but then it would be necessary to know the
-character type used...</p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="162"></a>162. Really "formatted input functions"?</h3>
-<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
-<p><b>Discussion:</b></p>
-<p>It appears to be somewhat nonsensical to consider the functions
-defined in the paragraphs 1 to 5 to be "Formatted input
-function" but since these functions are defined in a section
-labeled "Formatted input functions" it is unclear to me
-whether these operators are considered formatted input functions which
-have to conform to the "common requirements" from 27.6.1.2.1
-[istream.formatted.reqmts]: If this is the case, all manipulators, not
-just
-<tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is set
-(... but setting <tt>noskipws</tt> using the manipulator syntax would
-also skip whitespace :-)</p>
-
-<p>See also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a> for the same problem in formatted
-output</p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="163"></a>163. Return of <tt>gcount()</tt> after a call to <tt>gcount</tt></h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
-<p><b>Discussion:</b></p>
-<p>It is not clear which functions are to be considered unformatted
-input functions. As written, it seems that all functions in 27.6.1.3
-[istream.unformatted] are unformatted input functions. However, it does
-not
-really make much sense to construct a sentry object for
-<tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is unclear what
-happens to the <tt>gcount()</tt> if eg. <tt>gcount()</tt>,
-<tt>putback()</tt>, <tt>unget()</tt>, or <tt>sync()</tt> is called:
-These functions don't extract characters, some of them even
-"unextract" a character. Should this still be reflected in
-<tt>gcount()</tt>? Of course, it could be read as if after a call to
-<tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> (the last
-unformatted input function, <tt>gcount()</tt>, didn't extract any
-character) and after a call to <tt>putback()</tt> <tt>gcount()</tt>
-returns <tt>-1</tt> (the last unformatted input function
-<tt>putback()</tt> did "extract" back into the
-stream). Correspondingly for <tt>unget()</tt>. Is this what is
-intended? If so, this should be clarified. Otherwise, a corresponding
-clarification should be used.</p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="166"></a>166. Really "formatted output functions"?</h3>
-<p><b>Section:</b> 27.6.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a></p>
-<p><b>Discussion:</b></p>
-<p>From 27.6.2.6.1 [ostream.formatted.reqmts] it appears that all the functions
-defined in 27.6.2.6.3 [ostream.inserters] have to construct a
-<tt>sentry</tt> object. Is this really intended?</p>
-
-<p>This is basically the same problem as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a> but
-for output instead of input.</p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="177"></a>177. Complex operators cannot be explicitly instantiated</h3>
-<p><b>Section:</b> 26.3.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1999-07-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>A user who tries to explicitly instantiate a complex non-member operator will
-get compilation errors. Below is a simplified example of the reason why. The
-problem is that iterator_traits cannot be instantiated on a non-pointer type
-like float, yet when the compiler is trying to decide which operator+ needs to
-be instantiated it must instantiate the declaration to figure out the first
-argument type of a reverse_iterator operator.</p>
-<pre>namespace std {
-template &lt;class Iterator&gt;
-struct iterator_traits
-{
- typedef typename Iterator::value_type value_type;
-};
-
-template &lt;class T&gt; class reverse_iterator;
-
-// reverse_iterator operator+
-template &lt;class T&gt;
-reverse_iterator&lt;T&gt; operator+
-(typename iterator_traits&lt;T&gt;::difference_type, const reverse_iterator&lt;T&gt;&amp;);
-
-template &lt;class T&gt; struct complex {};
-
-// complex operator +
-template &lt;class T&gt;
-complex&lt;T&gt; operator+ (const T&amp; lhs, const complex&lt;T&gt;&amp; rhs)
-{ return complex&lt;T&gt;();}
-}
-
-// request for explicit instantiation
-template std::complex&lt;float&gt; std::operator+&lt;float&gt;(const float&amp;,
- const std::complex&lt;float&gt;&amp;);</pre>
-<p>See also c++-stdlib reflector messages: lib-6814, 6815, 6816.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Implementors can make minor changes and the example will
-work. Users are not affected in any case.</p> <p>According to John
-Spicer, It is possible to explicitly instantiate these operators using
-different syntax: change "std::operator+&lt;float&gt;" to
-"std::operator+".</p>
-
-<p>The proposed resolution of issue 120 is that users will not be able
-to explicitly instantiate standard library templates. If that
-resolution is accepted then library implementors will be the only ones
-that will be affected by this problem, and they must use the indicated
-syntax.</p>
-
-
-
-
-<hr>
-<h3><a name="178"></a>178. Should clog and cerr initially be tied to cout?</h3>
-<p><b>Section:</b> 27.3.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1999-07-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#narrow.stream.objects">issues</a> in [narrow.stream.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 27.3.1 says "After the object cerr is initialized,
-cerr.flags() &amp; unitbuf is nonzero. Its state is otherwise the same as
-required for ios_base::init (lib.basic.ios.cons). It doesn't say
-anything about the the state of clog. So this means that calling
-cerr.tie() and clog.tie() should return 0 (see Table 89 for
-ios_base::init effects).
-</p>
-<p>
-Neither of the popular standard library implementations
-that I tried does this, they both tie cerr and clog
-to &amp;cout. I would think that would be what users expect.
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The standard is clear as written.</p>
-<p>27.3.1/5 says that "After the object cerr is initialized, cerr.flags()
-&amp; unitbuf is nonzero. Its state is otherwise the same as required for
-ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the
-postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct
-ios_base::init to basic_ios::init().)</p>
-
-
-
-
-<hr>
-<h3><a name="188"></a>188. valarray helpers missing augmented assignment operators</h3>
-<p><b>Section:</b> 26.5.2.6 [valarray.cassign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 1999-08-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>26.5.2.6 defines augmented assignment operators
-valarray&lt;T&gt;::op=(const T&amp;), but fails to provide
-corresponding versions for the helper classes. Thus making the
-following illegal:</p>
-<blockquote>
-<pre>#include &lt;valarray&gt;
-
-int main()
-{
-std::valarray&lt;double&gt; v(3.14, 1999);
-
-v[99] *= 2.0; // Ok
-
-std::slice s(0, 50, 2);
-
-v[s] *= 2.0; // ERROR
-}</pre>
-</blockquote>
-<p>I can't understand the intent of that omission. It makes the
-valarray library less intuitive and less useful.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Although perhaps an unfortunate
-design decision, the omission is not a defect in the current
-standard.&nbsp; A future standard may wish to add the missing
-operators.</p>
-
-
-
-
-<hr>
-<h3><a name="191"></a>191. Unclear complexity for algorithms such as binary search</h3>
-<p><b>Section:</b> 25.3.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1999-10-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.binary.search">issues</a> in [alg.binary.search].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The complexity of binary_search() is stated as "At most
-log(last-first) + 2 comparisons", which seems to say that the
-algorithm has logarithmic complexity. However, this algorithms is
-defined for forward iterators. And for forward iterators, the need to
-step element-by-element results into linear complexity. But such a
-statement is missing in the standard. The same applies to
-lower_bound(), upper_bound(), and equal_range().&nbsp;<br>
-<br>
-However, strictly speaking the standard contains no bug here. So this
-might considered to be a clarification or improvement.
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The complexity is expressed in terms of comparisons, and that
-complexity can be met even if the number of iterators accessed is
-linear. Paragraph 1 already says exactly what happens to
-iterators.</p>
-
-
-
-
-<hr>
-<h3><a name="192"></a>192. a.insert(p,t) is inefficient and overconstrained</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
-<p><b>Discussion:</b></p>
-<p>As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from
-several problems:</p>
-<table border="1" cellpadding="5">
- <tbody><tr>
- <td><b>expression</b></td>
- <td><b>return type</b></td>
- <td><b>pre/post-condition</b></td>
- <td><b>complexity</b></td>
- </tr>
- <tr>
- <td><tt>a.insert(p,t)</tt></td>
- <td><tt>iterator</tt></td>
- <td>inserts t if and only if there is no element with key equivalent to the key of
- t in containers with unique keys; always inserts t in containers with equivalent
- keys. always returns the iterator pointing to the element with key equivalent to
- the key of t . iterator p is a hint pointing to where the insert should start to search.</td>
- <td>logarithmic in general, but amortized constant if t is inserted right after p .</td>
- </tr>
-</tbody></table>
-<p>1. For a container with unique keys, only logarithmic complexity is
-guaranteed if no element is inserted, even though constant complexity is always
-possible if p points to an element equivalent to t.</p>
-<p>2. For a container with equivalent keys, the amortized constant complexity
-guarantee is only useful if no key equivalent to t exists in the container.
-Otherwise, the insertion could occur in one of multiple locations, at least one
-of which would not be right after p.</p>
-<p>3. By guaranteeing amortized constant complexity only when t is inserted
-after p, it is impossible to guarantee constant complexity if t is inserted at
-the beginning of the container. Such a problem would not exist if amortized
-constant complexity was guaranteed if t is inserted before p, since there is
-always some p immediately before which an insert can take place.</p>
-<p>4. For a container with equivalent keys, p does not allow specification of
-where to insert the element, but rather only acts as a hint for improving
-performance. This negates the added functionality that p would provide if it
-specified where within a sequence of equivalent keys the insertion should occur.
-Specifying the insert location provides more control to the user, while
-providing no disadvantage to the container implementation.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 23.1.4 [associative.reqmts] paragraph 7, replace the row in table 69
-for a.insert(p,t) with the following two rows:</p>
-<table border="1" cellpadding="5">
- <tbody><tr>
- <td><b>expression</b></td>
- <td><b>return type</b></td>
- <td><b>pre/post-condition</b></td>
- <td><b>complexity</b></td>
- </tr>
- <tr>
- <td><tt>a_uniq.insert(p,t)</tt></td>
- <td><tt>iterator</tt></td>
- <td>inserts t if and only if there is no element with key equivalent to the
- key of t. returns the iterator pointing to the element with key equivalent
- to the key of t.</td>
- <td>logarithmic in general, but amortized constant if t is inserted right
- before p or p points to an element with key equivalent to t.</td>
- </tr>
- <tr>
- <td><tt>a_eq.insert(p,t)</tt></td>
- <td><tt>iterator</tt></td>
- <td>inserts t and returns the iterator pointing to the newly inserted
- element. t is inserted right before p if doing so preserves the container
- ordering.</td>
- <td>logarithmic in general, but amortized constant if t is inserted right
- before p.</td>
- </tr>
-</tbody></table>
-
-
-
-<p><b>Rationale:</b></p>
-<p>Too big a change.&nbsp; Furthermore, implementors report checking
-both before p and after p, and don't want to change this behavior.</p>
-
-
-
-
-
-<hr>
-<h3><a name="194"></a>194. rdbuf() functions poorly specified</h3>
-<p><b>Section:</b> 27.4.4 [ios] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1999-09-07</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In classic iostreams, base class ios had an rdbuf function that returned a
-pointer to the associated streambuf. Each derived class had its own rdbuf
-function that returned a pointer of a type reflecting the actual type derived
-from streambuf. Because in ARM C++, virtual function overrides had to have the
-same return type, rdbuf could not be virtual.</p>
-<p>In standard iostreams, we retain the non-virtual rdbuf function design, and
-in addition have an overloaded rdbuf function that sets the buffer pointer.
-There is no need for the second function to be virtual nor to be implemented in
-derived classes.</p>
-<p>Minor question: Was there a specific reason not to make the original rdbuf
-function virtual?</p>
-<p>Major problem: Friendly compilers warn about functions in derived classes
-that hide base-class overloads. Any standard implementation of iostreams will
-result in such a warning on each of the iostream classes, because of the
-ill-considered decision to overload rdbuf only in a base class.</p>
-<p>In addition, users of the second rdbuf function must use explicit
-qualification or a cast to call it from derived classes. An explicit
-qualification or cast to basic_ios would prevent access to any later overriding
-version if there was one.</p>
-<p>What I'd like to do in an implementation is add a using- declaration for the
-second rdbuf function in each derived class. It would eliminate warnings about
-hiding functions, and would enable access without using explicit qualification.
-Such a change I don't think would change the behavior of any valid program, but
-would allow invalid programs to compile:</p>
-<blockquote>
- <pre> filebuf mybuf;
- fstream f;
- f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre>
-</blockquote>
-<p>I'd like to suggest this problem as a defect, with the proposed resolution to
-require the equivalent of a using-declaration for the rdbuf function that is not
-replaced in a later derived class. We could discuss whether replacing the
-function should be allowed.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>For historical reasons, the standard is correct as written. There is a subtle difference between the base
-class <tt> rdbuf()</tt> and derived class <tt>rdbuf()</tt>. The derived
-class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base class
-<tt> rdbuf()</tt> will return the "current streambuf" if that has been changed by the variant you mention.</p>
-
-<p>Permission is not required to add such an extension. See
-17.4.4.4 [member.functions].</p>
-
-
-
-
-<hr>
-<h3><a name="196"></a>196. Placement new example has alignment problems</h3>
-<p><b>Section:</b> 18.5.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Herb Sutter <b>Date:</b> 1998-12-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a></p>
-<p><b>Discussion:</b></p>
-<p>The example in 18.5.1.3 [new.delete.placement] paragraph 4 reads: </p>
-
-<blockquote>
-
-<p>[Example: This can be useful for constructing an object at a known address:<br>
-<br>
-<tt>&nbsp;&nbsp; char place[sizeof(Something)];<br>
-&nbsp;&nbsp; Something* p = new (place) Something();<br>
-<br>
-</tt>end example] </p>
-
-</blockquote>
-
-<p>This example has potential alignment problems. </p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="197"></a>197. max_size() underspecified</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements], 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1999-10-21</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Must the value returned by max_size() be unchanged from call to call? </p>
-
-<p>Must the value returned from max_size() be meaningful? </p>
-
-<p>Possible meanings identified in lib-6827: </p>
-
-<p>1) The largest container the implementation can support given "best
-case" conditions - i.e. assume the run-time platform is "configured to
-the max", and no overhead from the program itself. This may possibly
-be determined at the point the library is written, but certainly no
-later than compile time.<br>
-<br>
-2) The largest container the program could create, given "best case"
-conditions - i.e. same platform assumptions as (1), but take into
-account any overhead for executing the program itself. (or, roughly
-"storage=storage-sizeof(program)"). This does NOT include any resource
-allocated by the program. This may (or may not) be determinable at
-compile time.<br>
-<br>
-3) The largest container the current execution of the program could
-create, given knowledge of the actual run-time platform, but again,
-not taking into account any currently allocated resource. This is
-probably best determined at program start-up.<br>
-<br>
-4) The largest container the current execution program could create at
-the point max_size() is called (or more correctly at the point
-max_size() returns :-), given it's current environment (i.e. taking
-into account the actual currently available resources). This,
-obviously, has to be determined dynamically each time max_size() is
-called. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>max_size() isn't useful for very many things, and the existing
- wording is sufficiently clear for the few cases that max_size() can
- be used for. None of the attempts to change the existing wording
- were an improvement.</p>
-
-<p>It is clear to the LWG that the value returned by max_size() can't
- change from call to call.</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="203"></a>203. basic_istream::sentry::sentry() is uninstantiable with ctype&lt;user-defined type&gt;</h3>
-<p><b>Section:</b> 27.6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt McClure and Dietmar Khl <b>Date:</b> 2000-01-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>27.6.1.1.2 Paragraph 4 states:</p>
-<blockquote>
- <p>To decide if the character c is a whitespace character, the constructor
- performs ''as if'' it executes the following code fragment:&nbsp;</p>
- <pre>const ctype&lt;charT&gt;&amp; ctype = use_facet&lt;ctype&lt;charT&gt; &gt;(is.getloc());
-if (ctype.is(ctype.space,c)!=0)
-// c is a whitespace character.</pre>
-</blockquote>
-
-<p> But Table 51 in 22.1.1.1.1 only requires an implementation to
-provide specializations for ctype&lt;char&gt; and
-ctype&lt;wchar_t&gt;. If sentry's constructor is implemented using
-ctype, it will be uninstantiable for a user-defined character type
-charT, unless the implementation has provided non-working (since it
-would be impossible to define a correct ctype&lt;charT&gt; specialization
-for an arbitrary charT) definitions of ctype's virtual member
-functions.</p>
-
-<p>
-It seems the intent the standard is that sentry should behave, in
-every respect, not just during execution, as if it were implemented
-using ctype, with the burden of providing a ctype specialization
-falling on the user. But as it is written, nothing requires the
-translation of sentry's constructor to behave as if it used the above
-code, and it would seem therefore, that sentry's constructor should be
-instantiable for all character types.
-</p>
-
-<p>
-Note: If I have misinterpreted the intent of the standard with
-respect to sentry's constructor's instantiability, then a note should
-be added to the following effect:
-</p>
-
-<blockquote><p>
-An implementation is forbidden from using the above code if it renders
-the constructor uninstantiable for an otherwise valid character
-type.
-</p></blockquote>
-
-<p>In any event, some clarification is needed.</p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>It is possible but not easy to instantiate on types other than char
-or wchar_t; many things have to be done first. That is by intention
-and is not a defect.</p>
-
-
-
-
-<hr>
-<h3><a name="204"></a>204. distance(first, last) when "last" is before "first"</h3>
-<p><b>Section:</b> 24.3.4 [iterator.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Rintala Matti <b>Date:</b> 2000-01-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Section 24.3.4 describes the function distance(first, last) (where first and
-last are iterators) which calculates "the number of increments or
-decrements needed to get from 'first' to 'last'".</p>
-<p>The function should work for forward, bidirectional and random access
-iterators, and there is a requirement 24.3.4.5 which states that "'last'
-must be reachable from 'first'".</p>
-<p>With random access iterators the function is easy to implement as "last
-- first".</p>
-<p>With forward iterators it's clear that 'first' must point to a place before
-'last', because otherwise 'last' would not be reachable from 'first'.</p>
-<p>But what about bidirectional iterators? There 'last' is reachable from
-'first' with the -- operator even if 'last' points to an earlier position than
-'first'. However, I cannot see how the distance() function could be implemented
-if the implementation does not know which of the iterators points to an earlier
-position (you cannot use ++ or -- on either iterator if you don't know which
-direction is the "safe way to travel").</p>
-<p>The paragraph 24.3.4.1 states that "for ... bidirectional iterators they
-use ++ to provide linear time implementations". However, the ++ operator is
-not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly
-mentions that distance() returns the number of increments _or decrements_,
-suggesting that it could return a negative number also for bidirectional
-iterators when 'last' points to a position before 'first'.</p>
-<p>Is a further requirement is needed to state that for forward and
-bidirectional iterators "'last' must be reachable from 'first' using the ++
-operator". Maybe this requirement might also apply to random access
-iterators so that distance() would work the same way for every iterator
-category?</p>
-
-
-<p><b>Rationale:</b></p>
-<p>"Reachable" is defined in the standard in 24.1 [iterator.requirements] paragraph 6.
-The definition is only in terms of operator++(). The LWG sees no defect in
-the standard.</p>
-
-
-
-
-<hr>
-<h3><a name="205"></a>205. numeric_limits unclear on how to determine floating point types</h3>
-<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-01-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In several places in 18.2.1.2 [numeric.limits.members], a member is
-described as "Meaningful for all floating point types."
-However, no clear method of determining a floating point type is
-provided.</p>
-
-<p>In 18.2.1.5 [numeric.special], paragraph 1 states ". . . (for
-example, epsilon() is only meaningful if is_integer is
-false). . ." which suggests that a type is a floating point type
-if is_specialized is true and is_integer is false; however, this is
-unclear.</p>
-
-<p>When clarifying this, please keep in mind this need of users: what
-exactly is the definition of floating point? Would a fixed point or
-rational representation be considered one? I guess my statement here
-is that there could also be types that are neither integer or
-(strictly) floating point.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>It is up to the implementor of a user define type to decide if it is a
-floating point type.</p>
-
-
-
-
-<hr>
-<h3><a name="207"></a>207. ctype&lt;char&gt; members return clause incomplete</h3>
-<p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Robert Klarer <b>Date:</b> 1999-11-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a></p>
-<p><b>Discussion:</b></p>
-<p>
-The <tt>widen</tt> and <tt>narrow</tt> member functions are described
-in 22.2.1.3.2, paragraphs 9-11. In each case we have two overloaded
-signatures followed by a <b>Returns</b> clause. The <b>Returns</b>
-clause only describes one of the overloads.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members]
-paragraph 10 from:</p>
-<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
-
-<p>to:</p>
-<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
-respectively.</p>
-
-<p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members] paragraph 11
-from:</p>
-<p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(low, high, to).</p>
-
-<p>to:</p>
-<p>&nbsp;&nbsp;&nbsp; Returns: do_narrow(c) or do_narrow(low, high, to),
-respectively.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, which addresses the same
-paragraphs.</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="213"></a>213. Math function overloads ambiguous</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Due to the additional overloaded versions of numeric functions for
-float and long double according to Section 26.5, calls such as int x;
-std::pow (x, 4) are ambiguous now in a standard conforming
-implementation. Current implementations solve this problem very
-different (overload for all types, don't overload for float and long
-double, use preprocessor, follow the standard and get
-ambiguities).</p> <p>This behavior should be standardized or at least
-identified as implementation defined.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>These math issues are an
-understood and accepted consequence of the design. They have
-been discussed several times in the past. Users must write casts
-or write floating point expressions as arguments.</p>
-
-
-
-
-<hr>
-<h3><a name="215"></a>215. Can a map's key_type be const?</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>A user noticed that this doesn't compile with the Rogue Wave library because
-the rb_tree class declares a key_allocator, and allocator&lt;const int&gt; is
-not legal, I think:</p>
-<blockquote>
- <pre>map &lt; const int, ... &gt; // legal?</pre>
-</blockquote>
-<p>which made me wonder whether it is legal for a map's key_type to be const. In
-email from Matt Austern he said:</p>
-<blockquote>
-<p>I'm not sure whether it's legal to declare a map with a const key type. I
-hadn't thought about that question until a couple weeks ago. My intuitive
-feeling is that it ought not to be allowed, and that the standard ought to say
-so. It does turn out to work in SGI's library, though, and someone in the
-compiler group even used it. Perhaps this deserves to be written up as an issue
-too.</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>The "key is assignable" requirement from table 69 in
-23.1.4 [associative.reqmts] already implies the key cannot be const.</p>
-
-
-
-
-<hr>
-<h3><a name="216"></a>216. setbase manipulator description flawed</h3>
-<p><b>Section:</b> 27.6.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Hyman Rosen <b>Date:</b> 2000-02-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#std.manip">issues</a> in [std.manip].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a></p>
-<p><b>Discussion:</b></p>
-<p>27.6.3 [std.manip] paragraph 5 says:</p>
-<blockquote>
-<pre>smanip setbase(int base);</pre>
-<p> Returns: An object s of unspecified type such that if out is an
-(instance of) basic_ostream then the expression out&lt;&lt;s behaves
-as if f(s) were called, in is an (instance of) basic_istream then the
-expression in&gt;&gt;s behaves as if f(s) were called. Where f can be
-defined as:</p>
-<pre>ios_base&amp; f(ios_base&amp; str, int base)
-{
- // set basefield
- str.setf(n == 8 ? ios_base::oct :
- n == 10 ? ios_base::dec :
- n == 16 ? ios_base::hex :
- ios_base::fmtflags(0), ios_base::basefield);
- return str;
-}</pre>
-</blockquote>
-<p>There are two problems here. First, f takes two parameters, so the
-description needs to say that out&lt;&lt;s and in&gt;&gt;s behave as if f(s,base)
-had been called. Second, f is has a parameter named base, but is written as if
-the parameter was named n.</p>
-<p>Actually, there's a third problem. The paragraph has grammatical errors.
-There needs to be an "and" after the first comma, and the "Where
-f" sentence fragment needs to be merged into its preceding sentence. You
-may also want to format the function a little better. The formatting above is
-more-or-less what the Standard contains.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The resolution of this defect is subsumed by the proposed resolution for
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>.</p>
-
-<p><i>[Tokyo: The LWG agrees that this is a defect and notes that it
-occurs additional places in the section, all requiring fixes.]</i></p>
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="218"></a>218. Algorithms do not use binary predicate objects for default comparisons</h3>
-<p><b>Section:</b> 25.3 [alg.sorting] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.sorting">issues</a> in [alg.sorting].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Many of the algorithms take an argument, pred, of template parameter type
-BinaryPredicate or an argument comp of template parameter type Compare. These
-algorithms usually have an overloaded version that does not take the predicate
-argument. In these cases pred is usually replaced by the use of operator== and
-comp is replaced by the use of operator&lt;.</p>
-<p>This use of hard-coded operators is inconsistent with other parts of the
-library, particularly the containers library, where equality is established
-using equal_to&lt;&gt; and ordering is established using less&lt;&gt;. Worse,
-the use of operator&lt;, would cause the following innocent-looking code to have
-undefined behavior:</p>
-<blockquote>
- <pre>vector&lt;string*&gt; vec;
-sort(vec.begin(), vec.end());</pre>
-</blockquote>
-<p>The use of operator&lt; is not defined for pointers to unrelated objects. If
-std::sort used less&lt;&gt; to compare elements, then the above code would be
-well-defined, since less&lt;&gt; is explicitly specialized to produce a total
-ordering of pointers.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This use of operator== and operator&lt; was a very deliberate, conscious, and
-explicitly made design decision; these operators are often more efficient. The
-predicate forms are available for users who don't want to rely on operator== and
-operator&lt;.</p>
-
-
-
-
-<hr>
-<h3><a name="219"></a>219. find algorithm missing version that takes a binary predicate argument</h3>
-<p><b>Section:</b> 25.1.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Future">NAD Future</a>
- <b>Submitter:</b> Pablo Halpern <b>Date:</b> 2000-03-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Future">NAD Future</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The find function always searches for a value using operator== to compare the
-value argument to each element in the input iterator range. This is inconsistent
-with other find-related functions such as find_end and find_first_of, which
-allow the caller to specify a binary predicate object to be used for determining
-equality. The fact that this can be accomplished using a combination of find_if
-and bind_1st or bind_2nd does not negate the desirability of a consistent,
-simple, alternative interface to find.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<blockquote>
-<p>In section 25.1.5 [alg.find], add a second prototype for find
-(between the existing prototype and the prototype for find_if), as
-follows:</p>
-<pre> template&lt;class InputIterator, class T, class BinaryPredicate&gt;
- InputIterator find(InputIterator first, InputIterator last,
- const T&amp; value, BinaryPredicate bin_pred);</pre>
-<p>Change the description of the return from:</p>
-<blockquote>
- <p>Returns: The first iterator i in the range [first, last) for which the following corresponding
- conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p>
-</blockquote>
-<p>&nbsp;to:</p>
-<blockquote>
- <p>Returns: The first iterator i in the range [first, last) for which the following&nbsp;
- corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
- != false. Return last if no such iterator is found.</p>
-</blockquote>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>This is request for a pure extension, so it is not a defect in the
-current standard.&nbsp; As the submitter pointed out, "this can
-be accomplished using a combination of find_if and bind_1st or
-bind_2nd".</p>
-
-
-
-
-<hr>
-<h3><a name="236"></a>236. ctype&lt;char&gt;::is() member modifies facet</h3>
-<p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 2000-04-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a></p>
-<p><b>Discussion:</b></p>
-<p>The description of the <tt>is()</tt> member in paragraph 4 of 22.2.1.3.2 [facet.ctype.char.members] is broken: According to this description, the
-second form of the <tt>is()</tt> method modifies the masks in the
-<tt>ctype</tt> object. The correct semantics if, of course, to obtain
-an array of masks. The corresponding method in the general case,
-ie. the <tt>do_is()</tt> method as described in 22.2.1.1.2 [locale.ctype.virtuals] paragraph 1 does the right thing.</p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>Change paragraph 4 from</p>
- <blockquote><p>
- The second form, for all *p in the range [low, high), assigns
- vec[p-low] to table()[(unsigned char)*p].
- </p></blockquote>
- <p>to become</p>
- <blockquote><p>
- The second form, for all *p in the range [low, high), assigns
- table()[(unsigned char)*p] to vec[p-low].
- </p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="244"></a>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3>
-<p><b>Section:</b> 25.1.5 [alg.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find">issues</a> in [alg.find].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Is the following implementation of <tt>find</tt> acceptable?</p>
-
-<pre> template&lt;class Iter, class X&gt;
- Iter find(Iter begin, Iter end, const X&amp; x)
- {
- X x1 = x; // this is the crucial statement
- while (begin != end &amp;&amp; *begin != x1)
- ++begin;
- return begin;
- }
-</pre>
-
-<p>If the answer is yes, then it is implementation-dependent as to
-whether the following fragment is well formed:</p>
-
-<pre> vector&lt;string&gt; v;
-
- find(v.begin(), v.end(), "foo");
-</pre>
-
-<p>At issue is whether there is a requirement that the third argument
-of find be CopyConstructible. There may be no problem here, but
-analysis is necessary.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>There is no indication in the standard that find's third argument
-is required to be Copy Constructible. The LWG believes that no such
-requirement was intended. As noted above, there are times when a user
-might reasonably pass an argument that is not Copy Constructible.</p>
-
-
-
-
-<hr>
-<h3><a name="245"></a>245. Which operations on <tt>istream_iterator</tt> trigger input operations?</h3>
-<p><b>Section:</b> 24.5.1 [istream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-05-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#istream.iterator">active issues</a> in [istream.iterator].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator">issues</a> in [istream.iterator].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>I do not think the standard specifies what operation(s) on istream
-iterators trigger input operations. So, for example:</p>
-
-<pre> istream_iterator&lt;int&gt; i(cin);
-
- int n = *i++;
-</pre>
-
-<p>I do not think it is specified how many integers have been read
-from cin. The number must be at least 1, of course, but can it be 2?
-More?</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The standard is clear as written: the stream is read every time
-operator++ is called, and it is also read either when the iterator is
-constructed or when operator* is called for the first time. In the
-example above, exactly two integers are read from cin.</p>
-
-<p>There may be a problem with the interaction between istream_iterator
-and some STL algorithms, such as find. There are no guarantees about
-how many times find may invoke operator++.</p>
-
-
-
-
-<hr>
-<h3><a name="246"></a>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Mark Rodgers <b>Date:</b> 2000-05-19</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a></p>
-<p><b>Discussion:</b></p>
-<p>Closed issue 192 raised several problems with the specification of
-this function, but was rejected as Not A Defect because it was too big
-a change with unacceptable impacts on existing implementations.
-However, issues remain that could be addressed with a smaller change
-and with little or no consequent impact.</p>
-
-<ol>
- <li><p> The specification is inconsistent with the original
- proposal and with several implementations.</p>
-
- <p>The initial implementation by Hewlett Packard only ever looked
- immediately <i>before</i> p, and I do not believe there was any
- intention to standardize anything other than this behavior.
- Consequently, current implementations by several leading
- implementors also look immediately before p, and will only insert
- after p in logarithmic time. I am only aware of one implementation
- that does actually look after p, and it looks before p as well. It
- is therefore doubtful that existing code would be relying on the
- behavior defined in the standard, and it would seem that fixing
- this defect as proposed below would standardize existing
- practice.</p></li>
-
- <li><p>
- The specification is inconsistent with insertion for sequence
- containers.</p>
-
- <p>This is difficult and confusing to teach to newcomers. All
- insert operations that specify an iterator as an insertion location
- should have a consistent meaning for the location represented by
- that iterator.</p></li>
-
- <li><p> As specified, there is no way to hint that the insertion
- should occur at the beginning of the container, and the way to hint
- that it should occur at the end is long winded and unnatural.</p>
-
- <p>For a container containing n elements, there are n+1 possible
- insertion locations and n+1 valid iterators. For there to be a
- one-to-one mapping between iterators and insertion locations, the
- iterator must represent an insertion location immediately before
- the iterator.</p></li>
-
- <li><p> When appending sorted ranges using insert_iterators,
- insertions are guaranteed to be sub-optimal.</p>
-
- <p>In such a situation, the optimum location for insertion is
- always immediately after the element previously inserted. The
- mechanics of the insert iterator guarantee that it will try and
- insert after the element after that, which will never be correct.
- However, if the container first tried to insert before the hint,
- all insertions would be performed in amortized constant
- time.</p></li>
-</ol>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make
-the following changes in the row for a.insert(p,t):</p>
-
-<p><i>assertion/note pre/post condition:</i>
-<br>Change the last sentence from</p>
- <blockquote><p>
- "iterator p is a hint pointing to where the insert should
- start to search."
- </p></blockquote>
-<p>to</p>
- <blockquote><p>
- "iterator p is a hint indicating that immediately before p
- may be a correct location where the insertion could occur."
- </p></blockquote>
-
-<p><i>complexity:</i><br>
-Change the words "right after" to "immediately before".</p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="249"></a>249. Return Type of <tt>auto_ptr::operator=</tt></h3>
-<p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Joseph Gottman <b>Date:</b> 2000-06-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>According to section 20.4.5, the function
-<tt>auto_ptr::operator=()</tt> returns a reference to an auto_ptr.
-The reason that <tt>operator=()</tt> usually returns a reference is to
-facilitate code like</p>
-
-<pre> int x,y,z;
- x = y = z = 1;
-</pre>
-
-<p>However, given analogous code for <tt>auto_ptr</tt>s,</p>
-<pre> auto_ptr&lt;int&gt; x, y, z;
- z.reset(new int(1));
- x = y = z;
-</pre>
-
-<p>the result would be that <tt>z</tt> and <tt>y</tt> would both be set to
-NULL, instead of all the <tt>auto_ptr</tt>s being set to the same value.
-This makes such cascading assignments useless and counterintuitive for
-<tt>auto_ptr</tt>s.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change <tt>auto_ptr::operator=()</tt> to return <tt>void</tt> instead
-of an <tt>auto_ptr</tt> reference.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The return value has uses other than cascaded assignments: a user can
-call an auto_ptr member function, pass the auto_ptr to a
-function, etc. Removing the return value could break working user
-code.</p>
-
-
-
-
-<hr>
-<h3><a name="257"></a>257. STL functional object and iterator inheritance.</h3>
-<p><b>Section:</b> 20.6.3 [base], 24.3.2 [iterator.basic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Robert Dick <b>Date:</b> 2000-08-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-According to the November 1997 Draft Standard, the results of deleting an
-object of a derived class through a pointer to an object of its base class are
-undefined if the base class has a non-virtual destructor. Therefore, it is
-potentially dangerous to publicly inherit from such base classes.
-</p>
-
-<p>Defect:
-<br>
-The STL design encourages users to publicly inherit from a number of classes
-which do nothing but specify interfaces, and which contain non-virtual
-destructors.
-</p>
-
-<p>Attribution:
-<br>
-Wil Evers and William E. Kempf suggested this modification for functional
-objects.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-When a base class in the standard library is useful only as an interface
-specifier, i.e., when an object of the class will never be directly
-instantiated, specify that the class contains a protected destructor. This
-will prevent deletion through a pointer to the base class without performance,
-or space penalties (on any implementation I'm aware of).
-</p>
-
-<p>
-As an example, replace...
-</p>
-
-<pre> template &lt;class Arg, class Result&gt;
- struct unary_function {
- typedef Arg argument_type;
- typedef Result result_type;
- };
-</pre>
-
-<p>
-... with...
-</p>
-
-<pre> template &lt;class Arg, class Result&gt;
- struct unary_function {
- typedef Arg argument_type;
- typedef Result result_type;
- protected:
- ~unary_function() {}
- };
-</pre>
-
-<p>
-Affected definitions:
-<br>
- &nbsp;20.3.1 [lib.function.objects] -- unary_function, binary_function
- <br>
- &nbsp;24.3.2 [lib.iterator.basic] -- iterator
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-The standard is clear as written; this is a request for change, not a
-defect in the strict sense. The LWG had several different objections
-to the proposed change. One is that it would prevent users from
-creating objects of type <tt>unary_function</tt> and
-<tt>binary_function</tt>. Doing so can sometimes be legitimate, if users
-want to pass temporaries as traits or tag types in generic code.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="267"></a>267. interaction of strstreambuf::overflow() and seekoff()</h3>
-<p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-10-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It appears that the interaction of the strstreambuf members overflow()
-and seekoff() can lead to undefined behavior in cases where defined
-behavior could reasonably be expected. The following program
-demonstrates this behavior:
-</p>
-
-<pre> #include &lt;strstream&gt;
-
- int main ()
- {
- std::strstreambuf sb;
- sb.sputc ('c');
-
- sb.pubseekoff (-1, std::ios::end, std::ios::in);
- return !('c' == sb.sgetc ());
- }
-</pre>
-
-<p>
-D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf&lt;&gt;(),
-which in turn sets all pointers to 0 in 27.5.2.1, p1.
-</p>
-
-<p>
-27.5.2.2.5, p1 says that basic_streambuf&lt;&gt;::sputc(c) calls
-overflow(traits::to_int_type(c)) if a write position isn't available (it
-isn't due to the above).
-</p>
-
-<p>
-D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at
-least one write position available (i.e., it allows the function to make
-any positive number of write positions available).
-</p>
-
-<p>
-D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see
-seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this
-case. newoff is then epptr() - eback().
-</p>
-
-<p>
-D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or
-gptr() == epptr() + off holds.
-</p>
-
-<p>
-If strstreambuf::overflow() made exactly one write position available
-then gptr() will be set to just before epptr(), and the program will
-return 0. Buf if the function made more than one write position
-available, epptr() and gptr() will both point past pptr() and the
-behavior of the program is undefined.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
- <p>Change the last sentence of D.7.1 [depr.strstreambuf] paragraph 4 from</p>
-
- <blockquote><p>
- Otherwise, seeklow equals gbeg and seekhigh is either pend, if
- pend is not a null pointer, or gend.
- </p></blockquote>
-
- <p>to become</p>
-
- <blockquote><p>
- Otherwise, seeklow equals gbeg and seekhigh is either gend if
- 0 == pptr(), or pbase() + max where max is the maximum value of
- pptr() - pbase() ever reached for this stream.
- </p></blockquote>
-
-<p><i>[
- pre-Copenhagen: Dietmar provided wording for proposed resolution.
-]</i></p>
-
-
-<p><i>[
- post-Copenhagen: Fixed a typo: proposed resolution said to fix
- 4.7.1, not D.7.1.
-]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>This is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>: it's not clear what it
-means to seek beyond the current area. Without resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a> we can't resolve this. As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>,
-the library working group does not wish to invest time nailing down
-corner cases in a deprecated feature.</p>
-
-
-
-
-
-<hr>
-<h3><a name="269"></a>269. cstdarg and unnamed parameters</h3>
-<p><b>Section:</b> 18.7 [support.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> J. Stephen Adamczyk <b>Date:</b> 2000-10-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.exception">issues</a> in [support.exception].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-One of our customers asks whether this is valid C++:
-</p>
-
-<pre> #include &lt;cstdarg&gt;
-
- void bar(const char *, va_list);
-
- void
- foo(const char *file, const char *, ...)
- {
- va_list ap;
- va_start(ap, file);
- bar(file, ap);
- va_end(ap);
- }
-</pre>
-
-<p>
-The issue being whether it is valid to use cstdarg when the final
-parameter before the "..." is unnamed. cstdarg is, as far
-as I can tell, inherited verbatim from the C standard. and the
-definition there (7.8.1.1 in the ISO C89 standard) refers to "the
-identifier of the rightmost parameter". What happens when there
-is no such identifier?
-</p>
-
-<p>
-My personal opinion is that this should be allowed, but some tweak
-might be required in the C++ standard.
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Not a defect, the C and C++ standards are clear. It is impossible to
-use varargs if the parameter immediately before "..." has no
-name, because that is the parameter that must be passed to va_start.
-The example given above is broken, because va_start is being passed
-the wrong parameter.
-</p>
-
-<p>
-There is no support for extending varargs to provide additional
-functionality beyond what's currently there. For reasons of C/C++
-compatibility, it is especially important not to make gratuitous
-changes in this part of the C++ standard. The C committee has already
-been requested not to touch this part of the C standard unless
-necessary.
-</p>
-
-
-
-
-<hr>
-<h3><a name="277"></a>277. Normative encouragement in allocator requirements unclear</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-11-07</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 20.1.5, paragraph 5, the standard says that "Implementors are
-encouraged to supply libraries that can accept allocators that
-encapsulate more general memory models and that support non-equal
-instances." This is intended as normative encouragement to
-standard library implementors. However, it is possible to interpret
-this sentence as applying to nonstandard third-party libraries.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.1.5, paragraph 5, change "Implementors" to
-"Implementors of the library described in this International
-Standard".
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes the normative encouragement is already
-sufficiently clear, and that there are no important consequences
-even if it is misunderstood.</p>
-
-
-
-
-
-<hr>
-<h3><a name="279"></a>279. const and non-const iterators should have equivalent typedefs</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-11-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-This came from an email from Steve Cleary to Fergus in reference to
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
-this in Toronto and believes it should be a separate issue.
-</p>
-
-<p>
-Steve said: "We may want to state that the const/non-const iterators must have
-the same difference type, size_type, and category."
-</p>
-
-<p>
-(Comment from Judy)
-I'm not sure if the above sentence should be true for all
-const and non-const iterators in a particular container, or if it means
-the container's iterator can't be compared with the container's
-const_iterator unless the above it true. I suspect the former.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In <b>Section:</b> 23.1 [container.requirements],
-table 65, in the assertion/note pre/post condition for X::const_iterator,
-add the following:
-</p>
-
-<blockquote>
-<p>
-typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type)
-</p>
-
-<p>
-typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type)
-</p>
-
-<p>
-typeid(X::const_iterator::category) == typeid(X::iterator::category)
-</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>Going through the types one by one: Iterators don't have a
-<tt>size_type</tt>. We already know that the difference types are
-identical, because the container requirements already say that the
-difference types of both X::iterator and X::const_iterator are both
-X::difference_type. The standard does not require that X::iterator
-and X::const_iterator have the same iterator category, but the LWG
-does not see this as a defect: it's possible to imagine cases in which
-it would be useful for the categories to be different.</p>
-
-<p>It may be desirable to require X::iterator and X::const_iterator to
-have the same value type, but that is a new issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>.)</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="287"></a>287. conflicting ios_base fmtflags</h3>
-<p><b>Section:</b> 27.4.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fmtflags.state">issues</a> in [fmtflags.state].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The Effects clause for ios_base::setf(fmtflags fmtfl) says
-"Sets fmtfl in flags()". What happens if the user first calls
-ios_base::scientific and then calls ios_base::fixed or vice-versa?
-This is an issue for all of the conflicting flags, i.e. ios_base::left
-and ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct.
-</p>
-
-<p>
-I see three possible solutions:
-</p>
-
-<ol>
-<li>Set ios_base::failbit whenever the user specifies a conflicting
-flag with one previously explicitly set. If the constructor is
-supposed to set ios_base::dec (see discussion below), then
-the user setting hex or oct format after construction will not
-set failbit. </li>
-<li>The last call to setf "wins", i.e. it clears any conflicting
-previous setting.</li>
-<li>All the flags that the user specifies are set, but when actually
-interpreting them, fixed always override scientific, right always
-overrides left, dec overrides hex which overrides oct.</li>
-</ol>
-
-<p>
-Most existing implementations that I tried seem to conform to resolution #3,
-except that when using the iomanip manipulator hex or oct then that always
-overrides dec, but calling setf(ios_base::hex) doesn't.
-</p>
-
-<p>
-There is a sort of related issue, which is that although the ios_base
-constructor says that each ios_base member has an indeterminate value
-after construction, all the existing implementations I tried explicitly set
-ios_base::dec.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-<tt>adjustfield</tt>, <tt>basefield</tt>, and <tt>floatfield</tt>
-are each multi-bit fields. It is possible to set multiple bits within
-each of those fields. (For example, <tt>dec</tt> and
-<tt>oct</tt>). These fields are used by locale facets. The LWG
-reviewed the way in which each of those three fields is used, and
-believes that in each case the behavior is well defined for any
-possible combination of bits. See for example Table 58, in 22.2.2.2.2
-[facet.num.put.virtuals], noting the requirement in paragraph 6 of that
-section.
-</p>
-<p>
-Users are advised to use manipulators, or else use the two-argument
-version of <tt>setf</tt>, to avoid unexpected behavior.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="289"></a>289. &lt;cmath&gt; requirements missing C float and long double versions</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
- In ISO/IEC 9899:1990 Programming Languages C we find the following
- concerning &lt;math.h&gt;:
-</p>
-
-<blockquote><p>
- 7.13.4 Mathematics &lt;math.h&gt;
- <br>
- The names of all existing functions declared in the &lt;math.h&gt;
- header, suffixed with f or l, are reserved respectively for
- corresponding functions with float and long double arguments
- are return values.
-</p></blockquote>
-
-<p>
- For example, <tt>float&nbsp;sinf(float)</tt>
- is reserved.
-</p>
-
-<p>
- In the C99 standard, &lt;math.h&gt; must contain declarations
- for these functions.
-</p>
-
-<p>
-So, is it acceptable for an implementor to add these prototypes to the
-C++ versions of the math headers? Are they required?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add these Functions to Table 80, section 26.5 and to Table 99,
-section C.2:
-</p>
-
-<pre> acosf asinf atanf atan2f ceilf cosf coshf
- expf fabsf floorf fmodf frexpf ldexpf
- logf log10f modff powf sinf sinhf sqrtf
- tanf tanhf
- acosl asinl atanl atan2l ceill cosl coshl
- expl fabsl floorl fmodl frexpl ldexpl
- logl log10l modfl powl sinl sinhl sqrtl
- tanl tanhl
-</pre>
-
-<p>
-There should probably be a note saying that these functions
-are optional and, if supplied, should match the description in
-the 1999 version of the C standard. In the next round
-of C++ standardization they can then become mandatory.
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The C90 standard, as amended, already permits (but does not
-require) these functions, and the C++ standard incorporates the
-C90 standard by reference. C99 is not an issue, because it is
-never referred to by the C++ standard.</p>
-
-
-
-
-
-<hr>
-<h3><a name="293"></a>293. Order of execution in transform algorithm</h3>
-<p><b>Section:</b> 25.2.4 [alg.transform] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 2001-01-04</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.transform">issues</a> in [alg.transform].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>This issue is related to issue 242. In case that the resolution
-proposed for issue 242 is accepted, we have have the following
-situation: The 4 numeric algorithms (accumulate and consorts) as well
-as transform would allow a certain category of side effects. The
-numeric algorithms specify that they invoke the functor "for
-every iterator i in the range [first, last) in order". transform,
-in contrast, would not give any guarantee regarding order of
-invocation of the functor, which means that the functor can be invoked
-in any arbitrary order.
-</p>
-
-<p>Why would that be a problem? Consider an example: say the
-transformator that is a simple enumerator ( or more generally
-speaking, "is order-sensitive" ). Since a standard
-compliant implementation of transform is free to invoke the enumerator
-in no definite order, the result could be a garbled enumeration.
-Strictly speaking this is not a problem, but it is certainly at odds
-with the prevalent understanding of transform as an algorithms that
-assigns "a new _corresponding_ value" to the output
-elements.
-</p>
-
-<p>All implementations that I know of invoke the transformator in
-definite order, namely starting from first and proceeding to last -
-1. Unless there is an optimization conceivable that takes advantage of
-the indefinite order I would suggest to specify the order, because it
-eliminate the uncertainty that users would otherwise have regarding
-the order of execution of their potentially order-sensitive function
-objects.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In section 25.2.3 - Transform [lib.alg.transform] change:</p>
-<blockquote><p>
--1- Effects: Assigns through every iterator i in the range [result,
-result + (last1 - first1)) a new corresponding
-value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
-(i - result), *(first2 + (i - result))).
-</p></blockquote>
-<p>to:</p>
-<blockquote><p>
--1- Effects: Computes values by invoking the operation op or binary_op
-for every iterator in the range [first1, last1) in order. Assigns through
-every iterator i in the range [result, result + (last1 - first1)) a new
-corresponding
-value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
-(i - result), *(first2 + (i - result))).
-</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>For Input Iterators an order is already guaranteed, because
-only one order is possible. If a user who passes a Forward
-Iterator to one of these algorithms really needs a specific
-order of execution, it's possible to achieve that effect by
-wrapping it in an Input Iterator adaptor.</p>
-
-
-
-
-
-<hr>
-<h3><a name="296"></a>296. Missing descriptions and requirements of pair operators</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The synopsis of the header <tt>&lt;utility&gt;</tt> in 20.2 [utility]
-lists the complete set of equality and relational operators for <tt>pair</tt>
-but the section describing the template and the operators only describes
-<tt>operator==()</tt> and <tt>operator&lt;()</tt>, and it fails to mention
-any requirements on the template arguments. The remaining operators are
-not mentioned at all.
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>20.2.1 [operators] paragraph 10 already specifies the semantics.
-That paragraph says that, if declarations of operator!=, operator&gt;,
-operator&lt;=, and operator&gt;= appear without definitions, they are
-defined as specified in 20.2.1 [operators]. There should be no user
-confusion, since that paragraph happens to immediately precede the
-specification of <tt>pair</tt>.</p>
-
-
-
-
-
-<hr>
-<h3><a name="302"></a>302. Need error indication from codecvt&lt;&gt;::do_length</h3>
-<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Gregory Bumgardner <b>Date:</b> 2001-01-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The effects of <tt>codecvt&lt;&gt;::do_length()</tt> are described in
-22.2.1.5.2, paragraph 10. As implied by that paragraph, and clarified
-in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <tt>codecvt&lt;&gt;::do_length()</tt> must
-process the source data and update the <tt>stateT</tt> argument just
-as if the data had been processed by <tt>codecvt&lt;&gt;::in()</tt>.
-However, the standard does not specify how <tt>do_length()</tt> would
-report a translation failure, should the source sequence contain
-untranslatable or illegal character sequences.
-</p>
-
-<p>
-The other conversion methods return an "error" result value
-to indicate that an untranslatable character has been encountered, but
-<tt>do_length()</tt> already has a return value (the number of source
-characters that have been processed by the method).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-This issue cannot be resolved without modifying the interface. An exception
-cannot be used, as there would be no way to determine how many characters
-have been processed and the state object would be left in an indeterminate
-state.
-</p>
-
-<p>
-A source compatible solution involves adding a fifth argument to length()
-and do_length() that could be used to return position of the offending
-character sequence. This argument would have a default value that would
-allow it to be ignored:
-</p>
-
-<pre> int length(stateT&amp; state,
- const externT* from,
- const externT* from_end,
- size_t max,
- const externT** from_next = 0);
-
- virtual
- int do_length(stateT&amp; state,
- const externT* from,
- const externT* from_end,
- size_t max,
- const externT** from_next);
-</pre>
-
-<p>
-Then an exception could be used to report any translation errors and
-the from_next argument, if used, could then be used to retrieve the
-location of the offending character sequence.
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The standard is already clear: the return value is the number of
-"valid complete characters". If it encounters an invalid sequence of
-external characters, it stops.</p>
-
-
-
-
-
-<hr>
-<h3><a name="304"></a>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3>
-<p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-02-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-We all "know" that input iterators are allowed to produce
-values when dereferenced of which there is no other in-memory copy.
-</p>
-
-<p>
-But: Table 72, with a careful reading, seems to imply that this can only be
-the case if the value_type has no members (e.g. is a built-in type).
-</p>
-
-<p>The problem occurs in the following entry:</p>
-
-<pre> a-&gt;m pre: (*a).m is well-defined
- Equivalent to (*a).m
-</pre>
-
-<p>
-<tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference
-type, but since <tt>operator-&gt;()</tt> must return a pointer for
-<tt>a-&gt;m</tt> to be well-formed, it needs something to return a
-pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be
-buffered somewhere to make a legal input iterator.
-</p>
-
-<p>I don't think this was intentional.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The current standard is clear and consistent. Input iterators that
- return rvalues are in fact implementable. They may in some cases
- require extra work, but it is still possible to define an operator-&gt;
- in such cases: it doesn't have to return a T*, but may return a
- proxy type. No change to the standard is justified.</p>
-
-
-
-
-
-<hr>
-<h3><a name="313"></a>313. set_terminate and set_unexpected question</h3>
-<p><b>Section:</b> 18.7.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2001-04-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-According to section 18.7.3.3 of the standard, std::terminate() is
-supposed to call the terminate_handler in effect immediately after
-evaluating the throw expression.
-</p>
-
-<p>
-Question: what if the terminate_handler in effect is itself
-std::terminate?
-</p>
-
-<p>For example:</p>
-
-<pre> #include &lt;exception&gt;
-
- int main () {
- std::set_terminate(std::terminate);
- throw 5;
- return 0;
- }
-</pre>
-
-<p>
-Is the implementation allowed to go into an infinite loop?
-</p>
-
-<p>
-I think the same issue applies to std::set_unexpected.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>Infinite recursion is to be expected: users who set the terminate
-handler to <tt>terminate</tt> are explicitly asking for <tt>terminate</tt>
-to call itself.</p>
-
-
-
-
-
-<hr>
-<h3><a name="314"></a>314. Is the stack unwound when terminate() is called?</h3>
-<p><b>Section:</b> 18.7.3.3 [terminate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-04-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#terminate">issues</a> in [terminate].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-The standard appears to contradict itself about whether the stack is
-unwound when the implementation calls terminate().
-</p>
-
-<p>From 18.7.3.3p2:</p>
-<blockquote><p>
- Calls the terminate_handler function in effect immediately
- after evaluating the throw-expression (lib.terminate.handler),
- if called by the implementation [...]
-</p></blockquote>
-
-<p>So the stack is guaranteed not to be unwound.</p>
-
-<p>But from 15.3p9:</p>
-<blockquote><p>
- [...]whether or not the stack is unwound before this call
- to terminate() is implementation-defined (except.terminate).
-</p></blockquote>
-
-<p>
-And 15.5.1 actually defines that in most cases the stack is unwound.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>There is definitely no contradiction between the core and library
-clauses; nothing in the core clauses says that stack unwinding happens
-after <tt>terminate</tt> is called. 18.7.3.3p2 does not say anything
-about when terminate() is called; it merely specifies which
-<tt>terminate_handler</tt> is used.</p>
-
-
-
-
-
-<hr>
-<h3><a name="323"></a>323. abs() overloads in different headers</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-04</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Currently the standard mandates the following overloads of
-abs():</p>
-
-<pre> abs(long), abs(int) in &lt;cstdlib&gt;
-
- abs(float), abs(double), abs(long double) in &lt;cmath&gt;
-
- template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp;) in &lt;complex&gt;
-
- template&lt;class T&gt; valarray&lt;T&gt; abs(const valarray&lt;T&gt;&amp;); in &lt;valarray&gt;
-</pre>
-
-<p>
-The problem is that having only some overloads visible of a function
-that works on "implicitly inter-convertible" types is dangerous in
-practice. The headers that get included at any point in a translation
-unit can change unpredictably during program
-development/maintenance. The wrong overload might be unintentionally
-selected.
-</p>
-
-<p>
-Currently, there is nothing that mandates the simultaneous visibility
-of these overloads. Indeed, some vendors have begun fastidiously
-reducing dependencies among their (public) headers as a QOI issue: it
-helps people to write portable code by refusing to compile unless all
-the correct headers are #included.
-</p>
-
-<p>The same issue may exist for other functions in the library.</p>
-
-<p>Redmond: PJP reports that C99 adds two new kinds of abs: complex,
-and int_max_abs.</p>
-
-<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#343">343</a>.</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-The situation is not sufficiently severe to warrant a change.
-</blockquote>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The programs that could potentially be broken by this situation are
- already fragile, and somewhat contrived: For example, a user-defined
- class that has conversion overloads both to <tt>long</tt> and
- to <tt>float</tt>. If <tt>x</tt> is a value of such a class, then
- <tt>abs(x)</tt> would give the <tt>long</tt> version if the user
- included &lt;cstdlib&gt;, the <tt>float</tt> version if the user
- included &lt;cmath&gt;, and would be diagnosed as ambiguous at
- compile time if the user included both headers. The LWG couldn't
- find an example of a program whose meaning would be changed (as
- opposed to changing it from well-formed to ill-formed) simply by
- adding another standard header.</p>
-
-<p>Since the harm seems minimal, and there don't seem to be any simple
- and noninvasive solutions, this is being closed as NAD. It is
- marked as "Future" for two reasons. First, it might be useful to
- define an <tt>&lt;all&gt;</tt> header that would include all
- Standard Library headers. Second, we should at least make sure that
- future library extensions don't make this problem worse.</p>
-
-
-
-
-
-<hr>
-<h3><a name="326"></a>326. Missing typedef in moneypunct_byname</h3>
-<p><b>Section:</b> 22.2.6.4 [locale.moneypunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-05</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The definition of the moneypunct facet contains the typedefs char_type
-and string_type. Only one of these names, string_type, is defined in
-the derived facet, moneypunct_byname.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>For consistency with the numpunct facet, add a typedef for
-char_type to the definition of the moneypunct_byname facet in
-22.2.6.4 [locale.moneypunct.byname].</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The absence of the typedef is irrelevant. Users can still access
-the typedef, because it is inherited from the base class.</p>
-
-
-
-
-
-<hr>
-<h3><a name="330"></a>330. Misleading "exposition only" value in class locale definition</h3>
-<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The "exposition only" value of the std::locale::none constant shown in
-the definition of class locale is misleading in that it on many
-systems conflicts with the value assigned to one if the LC_XXX
-constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE
-on Linux and SunOS). This causes incorrect behavior when such a
-constant is passed to one of the locale member functions that accept a
-locale::category argument and interpret it as either the C LC_XXX
-constant or a bitmap of locale::category values. At least three major
-implementations adopt the suggested value without a change and
-consequently suffer from this problem.
-</p>
-
-<p>
-For instance, the following code will (presumably) incorrectly copy facets
-belonging to the collate category from the German locale on AIX:
-</p>
-
-<pre> std::locale l (std::locale ("C"), "de_DE", std::locale::none);
-</pre>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG agrees that it may be difficult to implement locale member
-functions in such a way that they can take either <tt>category</tt>
-arguments or the LC_ constants defined in &lt;cctype&gt;. In light of
-this requirement (22.1.1.1.1 [locale.category], paragraph 2), and in light
-of the requirement in the preceding paragraph that it is possible to
-combine <tt>category</tt> bitmask elements with bitwise operations,
-defining the <tt>category</tt> elements is delicate,
-particularly if an implementor is constrained to work with a
-preexisting C library. (Just using the existing LC_ constants would
-not work in general.) There's no set of "exposition only" values that
-could give library implementors proper guidance in such a delicate
-matter. The non-normative example we're giving is no worse than
-any other choice would be.</p>
-
-<p>See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>.</p>
-
-
-
-
-
-<hr>
-<h3><a name="332"></a>332. Consider adding increment and decrement operators to std::fpos&lt; T &gt; </h3>
-<p><b>Section:</b> 27.4.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Increment and decrement operators are missing from
-Table 88 -- Position type requirements in 27.4.3 [fpos].
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Table 88 (section 27.4.3) -- Position type requirements
-be updated to include increment and decrement operators.
-</p>
-
-<pre>expression return type operational note
-
-++p fpos&amp; p += O(1)
-p++ fpos { P tmp = p;
- ++p;
- return tmp; }
---p fpos&amp; p -= O(1)
-p-- fpos { P tmp = p;
- --p;
- return tmp; }
-</pre>
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes this is a request for extension, not a defect
-report. Additionally, nobody saw a clear need for this extension;
-<tt>fpos</tt> is used only in very limited ways.</p>
-
-
-
-
-
-<hr>
-<h3><a name="344"></a>344. grouping + showbase</h3>
-<p><b>Section:</b> 22.2.2 [category.numeric] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-10-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-When both grouping and showbase are active and the basefield is octal,
-does the leading 0 participate in the grouping or not? For example,
-should one format as: 0,123,456 or 0123,456?
-</p>
-<p>
-An analogy can be drawn with hexadecimal. It appears that 0x123,456 is
-preferred over 0x,123,456. However, this analogy is not universally
-accepted to apply to the octal base. The standard is not clear on how
-to format (or parse) in this manner.
-</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Insert into 22.2.3.1.2 [facet.numpunct.virtuals] paragraph 3, just before the last
-sentence:
-</p>
-<blockquote><p>
-The leading hexadecimal base specifier "0x" does not participate in
-grouping. The leading '0' octal base specifier may participate in
-grouping. It is unspecified if the leading '0' participates in
-formatting octal numbers. In parsing octal numbers, the implementation
-is encouraged to accept both the leading '0' participating in the
-grouping, and not participating (e.g. 0123,456 or 0,123,456).
-</p></blockquote>
-
-<p><b>Rationale:</b></p>
-<p>
-The current behavior may be unspecified, but it's not clear that it
-matters. This is an obscure corner case, since grouping is usually
-intended for the benefit of humans and oct/hex prefixes are usually
-intended for the benefit of machines. There is not a strong enough
-consensus in the LWG for action.
-</p>
-
-
-
-
-<hr>
-<h3><a name="348"></a>348. Minor issue with std::pair operator&lt;</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-10-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a></p>
-<p><b>Discussion:</b></p>
-
-
-<p>
-The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
-operator&lt; on any pair type which contains a pointer.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 20.2.3 [pairs] paragraph 6, replace:</p>
-<pre> Returns: x.first &lt; y.first || (!(y.first &lt; x.first) &amp;&amp; x.second &lt;
- y.second).
-</pre>
-<p>With:</p>
-<pre> Returns: std::less&lt;T1&gt;()( x.first, y.first ) ||
- (!std::less&lt;T1&gt;()( y.first, x.first) &amp;&amp;
- std::less&lt;T2&gt;()( x.second, y.second ) )
-</pre>
-
-
-
-<p><b>Rationale:</b></p>
-<p>This is an instance of a much more general problem. If we want
- operator&lt; to translate to std::less for pairs of pointers, where
- do we draw the line? The same issue applies to individual
- pointers, smart pointer wrappers, std::vector&lt;T*&gt;, and so
- on.</p>
-
-<p>Andy Koenig suggests that the real issue here is that we aren't
- distinguishing adequately between two different orderings, a
- "useful ordering" and a "canonical ordering" that's used just
- because we sometimes need <i>some</i> ordering without caring much
- which ordering it is. Another example of the later is typeinfo's
- <tt>before</tt>.</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="350"></a>350. allocator&lt;&gt;::address</h3>
-<p><b>Section:</b> 20.7.5.1 [allocator.members], 20.1.2 [allocator.requirements], 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 2001-10-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a></p>
-<p><b>Discussion:</b></p>
-<p>See c++std-lib-9006 and c++std-lib-9007. This issue is taken
-verbatim from -9007.</p>
-
-<p>
-The core language feature allowing definition of operator&amp;() applied
-to any non-builtin type makes that operator often unsafe to use in
-implementing libraries, including the Standard Library. The result
-is that many library facilities fail for legal user code, such as
-the fragment</p>
-<pre> class A { private: A* operator&amp;(); };
- std::vector&lt;A&gt; aa;
-
- class B { };
- B* operator&amp;(B&amp;) { return 0; }
- std::vector&lt;B&gt; ba;
-</pre>
-
-<p>
-In particular, the requirements table for Allocator (Table 32) specifies
-no semantics at all for member address(), and allocator&lt;&gt;::address is
-defined in terms of unadorned operator &amp;.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.6.1.1, Change the definition of allocator&lt;&gt;::address from:</p>
-<blockquote><p>
- Returns: &amp;x
-</p></blockquote>
-
-<p>to:</p>
-
-<p>
- Returns: The value that the built in operator&amp;(x) would return if not
- overloaded.
-</p>
-
-<p>
-In 20.1.6, Table 32, add to the Notes column of the a.address(r) and
-a.address(s) lines, respectively:
-</p>
-
-<pre> allocator&lt;T&gt;::address(r)
- allocator&lt;T&gt;::address(s)
-</pre>
-
-<p>In addition, in clause 17.4.1.1, add a statement:</p>
-
-<blockquote><p>
- The Standard Library does not apply operator&amp; to any type for which
- operator&amp; may be overloaded.
-</p></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes both examples are ill-formed. The contained type
-is required to be CopyConstructible (20.1.1 [utility.arg.requirements]), and that
-includes the requirement that &amp;t return the usual types and
-values. Since allocators are intended to be used in conjunction with
-containers, and since the CopyConstructible requirements appear to
-have been written to deal with the concerns of this issue, the LWG
-feels it is NAD unless someone can come up with a well-formed example
-exhibiting a problem.</p>
-
-<p>It may well be that the CopyConstructible requirements are too
- restrictive and that either the container requirements or the
- CopyConstructive requirements should be relaxed, but that's a far
- larger issue. Marking this issue as "future" as a pointer to that
- larger issue.</p>
-
-
-
-
-
-<hr>
-<h3><a name="351"></a>351. unary_negate and binary_negate: struct or class?</h3>
-<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Dale Riley <b>Date:</b> 2001-11-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 20.6 [function.objects] the header &lt;functional&gt; synopsis declares
-the unary_negate and binary_negate function objects as struct.
-However in 20.6.10 [negators] the unary_negate and binary_negate
-function objects are defined as class. Given the context, they are
-not "basic function objects" like negate, so this is either a typo or
-an editorial oversight.
-</p>
-
-<p><i>[Taken from comp.std.c++]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the synopsis to reflect the useage in 20.6.10 [negators]</p>
-
-<p><i>[Curaao: Since the language permits "struct", the LWG
-views this as NAD. They suggest, however, that the Project Editor
-might wish to make the change as editorial.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="353"></a>353. <tt>std::pair</tt> missing template assignment</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-12-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The class template <tt>std::pair</tt> defines a template ctor (20.2.2, p4) but
-no template assignment operator. This may lead to inefficient code since
-assigning an object of <tt>pair&lt;C, D&gt;</tt> to <tt>pair&lt;A, B&gt;</tt>
-where the types <tt>C</tt> and <tt>D</tt> are distinct from but convertible to
-<tt>A</tt> and <tt>B</tt>, respectively, results in a call to the template copy
-ctor to construct an unnamed temporary of type <tt>pair&lt;A, B&gt;</tt>
-followed by an ordinary (perhaps implicitly defined) assignment operator,
-instead of just a straight assignment.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following declaration to the definition of <tt>std::pair</tt>:
-</p>
-<pre> template&lt;class U, class V&gt;
- pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
-</pre>
-<p>
-And also add a paragraph describing the effects of the function template to the
-end of 20.2.2:
-</p>
-<pre> template&lt;class U, class V&gt;
- pair&amp; operator=(const pair&lt;U, V&gt; &amp;p);
-</pre>
-<p>
- <b>Effects</b>: <tt>first = p.first;</tt>
- <tt>second = p.second;</tt>
- <b>Returns</b>: <tt>*this</tt>
-</p>
-
-<p><i>[Curaao: There is no indication this is was anything other than
-a design decision, and thus NAD.&nbsp; May be appropriate for a future
-standard.]</i></p>
-
-
-<p><i>[
-Pre Bellevue: It was recognized that this was taken care of by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>,
-and thus moved from NAD Future to NAD Editorial.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="356"></a>356. Meaning of ctype_base::mask enumerators</h3>
-<p><b>Section:</b> 22.2.1 [category.ctype] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-01-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#category.ctype">issues</a> in [category.ctype].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>What should the following program print?</p>
-
-<pre> #include &lt;locale&gt;
- #include &lt;iostream&gt;
-
- class my_ctype : public std::ctype&lt;char&gt;
- {
- typedef std::ctype&lt;char&gt; base;
- public:
- my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
- {
- std::copy(base::classic_table(), base::classic_table() + base::table_size,
- my_table);
- my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
- }
- private:
- mask my_table[base::table_size];
- };
-
- int main()
- {
- my_ctype ct;
- std::cout &lt;&lt; "isspace: " &lt;&lt; ct.is(std::ctype_base::space, '_') &lt;&lt; " "
- &lt;&lt; "isalpha: " &lt;&lt; ct.is(std::ctype_base::alpha, '_') &lt;&lt; std::endl;
- }
-</pre>
-
-<p>The goal is to create a facet where '_' is treated as whitespace.</p>
-
-<p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0". On
-Microsoft C++ it prints "isspace: 1 isalpha: 1".</p>
-
-<p>
-I believe that both implementations are legal, and the standard does not
-give enough guidance for users to be able to use std::ctype's
-protected interface portably.</p>
-
-<p>
-The above program assumes that ctype_base::mask enumerators like
-<tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
-say that a character is both a space and a printing character is to or
-those two enumerators together. This is suggested by the "exposition
-only" values in 22.2.1 [category.ctype], but it is nowhere specified in
-normative text. An alternative interpretation is that the more
-specific categories subsume the less specific. The above program
-gives the results it does on the Microsoft compiler because, on that
-compiler, <tt>print</tt> has all the bits set for each specific
-printing character class.
-</p>
-
-<p>From the point of view of std::ctype's public interface, there's no
-important difference between these two techniques. From the point of
-view of the protected interface, there is. If I'm defining a facet
-that inherits from std::ctype&lt;char&gt;, I'm the one who defines the
-value that table()['a'] returns. I need to know what combination of
-mask values I should use. This isn't so very esoteric: it's exactly
-why std::ctype has a protected interface. If we care about users
-being able to write their own ctype facets, we have to give them a
-portable way to do it.
-</p>
-
-<p>
-Related reflector messages:
-lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
-lib-9277, lib-9279.
-</p>
-
-<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> is related, but not identical. The
-proposed resolution if issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> says that
-ctype_base::mask must be a bitmask type. It does not say that the
-ctype_base::mask elements are bitmask elements, so it doesn't
-directly affect this issue.</p>
-
-<p>More comments from Benjamin Kosnik, who believes that
-that C99 compatibility essentially requires what we're
-calling option 1 below.</p>
-
-<blockquote>
-<pre>I think the C99 standard is clear, that isspace -&gt; !isalpha.
---------
-
-#include &lt;locale&gt;
-#include &lt;iostream&gt;
-
-class my_ctype : public std::ctype&lt;char&gt;
-{
-private:
- typedef std::ctype&lt;char&gt; base;
- mask my_table[base::table_size];
-
-public:
- my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
- {
- std::copy(base::classic_table(), base::classic_table() + base::table_size,
- my_table);
- mask both = base::print | base::space;
- my_table[static_cast&lt;mask&gt;('_')] = both;
- }
-};
-
-int main()
-{
- using namespace std;
- my_ctype ct;
- cout &lt;&lt; "isspace: " &lt;&lt; ct.is(ctype_base::space, '_') &lt;&lt; endl;
- cout &lt;&lt; "isprint: " &lt;&lt; ct.is(ctype_base::print, '_') &lt;&lt; endl;
-
- // ISO C99, isalpha iff upper | lower set, and !space.
- // 7.5, p 193
- // -&gt; looks like g++ behavior is correct.
- // 356 -&gt; bitmask elements are required for ctype_base
- // 339 -&gt; bitmask type required for mask
- cout &lt;&lt; "isalpha: " &lt;&lt; ct.is(ctype_base::alpha, '_') &lt;&lt; endl;
-}
-</pre>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Informally, we have three choices:</p>
-<ol>
-<li>Require that the enumerators are disjoint (except for alnum and
-graph)</li>
-<li>Require that the enumerators are not disjoint, and specify which
-of them subsume which others. (e.g. mandate that lower includes alpha
-and print)</li>
-<li>Explicitly leave this unspecified, which the result that the above
-program is not portable.</li>
-</ol>
-
-<p>Either of the first two options is just as good from the standpoint
-of portability. Either one will require some implementations to
-change.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG agrees that this is a real ambiguity, and that both
-interpretations are conforming under the existing standard. However,
-there's no evidence that it's causing problems for real users. Users
-who want to define ctype facets portably can test the ctype_base masks
-to see which interpretation is being used.</p>
-
-
-
-
-
-<hr>
-<h3><a name="357"></a>357. &lt;cmath&gt; float functions cannot return HUGE_VAL</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-02-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The float versions of the math functions have no meaningful value to return
-for a range error. The long double versions have a value they can return,
-but it isn't necessarily the most reasonable value.
-</p>
-
-<p>
-Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long
-double overloaded versions of these functions, with the same semantics,"
-referring to the math functions from the C90 standard.
-</p>
-
-<p>
-The C90 standard, in section 7.5.1, paragraph 3, says that functions return
-"the value of the macro HUGE_VAL" when they encounter a range error.
-Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a
-positive double expression, not necessarily representable as a float."
-</p>
-
-<p>
-Therefore, the float versions of the math functions have no way to
-signal a range error. <i>[Curaao: The LWG notes that this isn't
-strictly correct, since errno is set.]</i> The semantics require that they
-return HUGE_VAL, but they cannot because HUGE_VAL might not be
-representable as a float.
-</p>
-
-<p>
-The problem with long double functions is less severe because HUGE_VAL is
-representable as a long double. On the other hand, it might not be a "huge"
-long double value, and might fall well within the range of normal return
-values for a long double function. Therefore, it does not make sense for a
-long double function to return a double (HUGE_VAL) for a range error.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Curaao: C99 was faced with a similar problem, which they fixed by
-adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p>
-
-<p>C++ must also fix, but it should be done in the context of the
-general C99 based changes to C++, not via DR. Thus the LWG in Curaao
-felt the resolution should be NAD, FUTURE, but the issue is being held
-open for one more meeting to ensure LWG members not present during the
-discussion concur.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Will be fixed as part of more general work in the TR.</p>
-
-
-
-
-
-<hr>
-<h3><a name="361"></a>361. num_get&lt;&gt;::do_get (..., void*&amp;) checks grouping</h3>
-<p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-22.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only
-for integral types (issue 282 suggests that this should be done for
-all arithmetic types).
-</p>
-
-<p>
-22.2.2.1.2, p12 requires that grouping be checked for all extractors
-including that for <tt>void*</tt>.
-</p>
-
-<p>
-I don't think that's right. <tt>void*</tt> values should not be checked for
-grouping, should they? (Although if they should, then <tt>num_put</tt> needs
-to write them out, otherwise their extraction will fail.)
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the first sentence of 22.2.2.2.2, p12 from
-</p>
-<blockquote><p>
- Digit grouping is checked. That is, the positions of discarded
- separators is examined for consistency with
- use_facet&lt;numpunct&lt;charT&gt; &gt;(loc).grouping().
- If they are not consistent then ios_base::failbit is assigned
- to err.
-</p></blockquote>
-
-<p>to</p>
-<blockquote><p>
- Except for conversions to void*, digit grouping is checked...
-</p></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>This would be a change: as it stands, the standard clearly
- specifies that grouping applies to void*. A survey of existing
- practice shows that most existing implementations do that, as they
- should.</p>
-
-
-
-
-
-<hr>
-<h3><a name="366"></a>366. Excessive const-qualification</h3>
-<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The following member functions are declared const, yet return non-const
-pointers. We believe they are should be changed, because they allow code
-that may surprise the user. See document N1360 for details and
-rationale.
-</p>
-
-<p><i>[Santa Cruz: the real issue is that we've got const member
-functions that return pointers to non-const, and N1360 proposes
-replacing them by overloaded pairs. There isn't a consensus about
-whether this is a real issue, since we've never said what our
-constness policy is for iostreams. N1360 relies on a distinction
-between physical constness and logical constness; that distinction, or
-those terms, does not appear in the standard.]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.4.4 and 27.4.4.2</p>
-<p>Replace</p>
-<pre> basic_ostream&lt;charT,traits&gt;* tie() const;
-</pre>
-<p>with</p>
-<pre> basic_ostream&lt;charT,traits&gt;* tie();
- const basic_ostream&lt;charT,traits&gt;* tie() const;
-</pre>
-
-<p>and replace</p>
-<pre> basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
-</pre>
-<p>with</p>
-<pre> basic_streambuf&lt;charT,traits&gt;* rdbuf();
- const basic_streambuf&lt;charT,traits&gt;* rdbuf() const;
-</pre>
-
-<p>In 27.5.2 and 27.5.2.3.1</p>
-<p>Replace</p>
-<pre> char_type* eback() const;
-</pre>
-<p>with</p>
-<pre> char_type* eback();
- const char_type* eback() const;
-</pre>
-
-<p>Replace</p>
-<pre> char_type gptr() const;
-</pre>
-<p>with</p>
-<pre> char_type* gptr();
- const char_type* gptr() const;
-</pre>
-
-<p>Replace</p>
-<pre> char_type* egptr() const;
-</pre>
-<p>with</p>
-<pre> char_type* egptr();
- const char_type* egptr() const;
-</pre>
-
-<p>In 27.5.2 and 27.5.2.3.2</p>
-<p>Replace</p>
-<pre> char_type* pbase() const;
-</pre>
-<p>with</p>
-<pre> char_type* pbase();
- const char_type* pbase() const;
-</pre>
-
-<p>Replace</p>
-<pre> char_type* pptr() const;
-</pre>
-<p>with</p>
-<pre> char_type* pptr();
- const char_type* pptr() const;
-</pre>
-
-<p>Replace</p>
-<pre> char_type* epptr() const;
-</pre>
-<p>with</p>
-<pre> char_type* epptr();
- const char_type* epptr() const;
-</pre>
-
-<p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p>
-<p>Replace</p>
-<pre> basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
-</pre>
-<p>with</p>
-<pre> basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf();
- const basic_stringbuf&lt;charT,traits,Allocator&gt;* rdbuf() const;
-</pre>
-
-<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
-<p>Replace</p>
-<pre> basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
-</pre>
-<p>with</p>
-<pre> basic_filebuf&lt;charT,traits&gt;* rdbuf();
- const basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
-</pre>
-
-
-<p><b>Rationale:</b></p>
-<p>The existing specification is a bit sloppy, but there's no
- particular reason to change this other than tidiness, and there are
- a number of ways in which streams might have been designed
- differently if we were starting today. There's no evidence that the
- existing constness policy is harming users. We might consider
- a different constness policy as part of a full stream redesign.</p>
-
-
-
-
-
-<hr>
-<h3><a name="367"></a>367. remove_copy/remove_copy_if and Input Iterators</h3>
-<p><b>Section:</b> 25.2.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Anthony Williams <b>Date:</b> 2002-05-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-remove_copy and remove_copy_if (25.2.8 [alg.remove]) permit their
-input range to be marked with Input Iterators. However, since two
-operations are required against the elements to copy (comparison and
-assigment), when the input range uses Input Iterators, a temporary
-copy must be taken to avoid dereferencing the iterator twice. This
-therefore requires the value type of the InputIterator to be
-CopyConstructible. If the iterators are at least Forward Iterators,
-then the iterator can be dereferenced twice, or a reference to the
-result maintained, so the temporary is not required.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add "If InputIterator does not meet the requirements of forward
-iterator, then the value type of InputIterator must be copy
-constructible. Otherwise copy constructible is not required." to
-25.2.8 [alg.remove] paragraph 6.
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The assumption is that an input iterator can't be dereferenced
- twice. There's no basis for that assumption in the Standard.</p>
-
-
-
-
-
-<hr>
-<h3><a name="368"></a>368. basic_string::replace has two "Throws" paragraphs</h3>
-<p><b>Section:</b> 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2002-06-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-21.3.6.6 [string::replace] basic_string::replace, second
-signature, given in paragraph 1, has two "Throws" paragraphs (3 and
-5).
-</p>
-
-<p>
-In addition, the second "Throws" paragraph (5) includes specification
-(beginning with "Otherwise, the function replaces ...") that should be
-part of the "Effects" paragraph.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>This is editorial. Both "throws" statements are true. The bug is
- just that the second one should be a sentence, part of the "Effects"
- clause, not a separate "Throws". The project editor has been
- notified.</p>
-
-
-
-
-
-<hr>
-<h3><a name="372"></a>372. Inconsistent description of stdlib exceptions</h3>
-<p><b>Section:</b> 17.4.4.9 [res.on.exception.handling], 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Randy Maddox <b>Date:</b> 2002-07-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>Paragraph 3 under clause 17.4.4.9 [res.on.exception.handling], Restrictions on
-Exception Handling, states that "Any other functions defined in the
-C++ Standard Library that do not have an exception-specification may
-throw implementation-defined exceptions unless otherwise specified."
-This statement is followed by a reference to footnote 178 at the
-bottom of that page which states, apparently in reference to the C++
-Standard Library, that "Library implementations are encouraged (but
-not required) to report errors by throwing exceptions from (or derived
-from) the standard exceptions."</p>
-
-<p>These statements appear to be in direct contradiction to clause
-18.6.1 [type.info], which states "The class exception defines the
-base class for the types of objects thrown as exceptions by the C++
-Standard library components ...".</p>
-
-<p>Is this inconsistent?</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>Clause 17 is setting the overall library requirements, and it's
- clear and consistent. This sentence from Clause 18 is descriptive,
- not setting a requirement on any other class.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="374"></a>374. moneypunct::frac_digits returns int not unsigned</h3>
-<p><b>Section:</b> 22.2.6.3.1 [locale.moneypunct.members], 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-08</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In section 22.2.6.3.1 [locale.moneypunct.members], frac_digits() returns type
-"int". This implies that frac_digits() might return a negative value,
-but a negative value is nonsensical. It should return "unsigned".
-</p>
-
-<p>
-Similarly, in section 22.2.6.3.2 [locale.moneypunct.virtuals], do_frac_digits()
-should return "unsigned".
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>Regardless of whether the return value is int or unsigned, it's
-always conceivable that frac_digits might return a nonsensical
-value. (Is 4294967295 really any better than -1?) The clients of
-moneypunct, the get and put facets, can and do perform range
-checks.</p>
-
-
-
-
-
-<hr>
-<h3><a name="377"></a>377. basic_string::insert and length_error</h3>
-<p><b>Section:</b> 21.3.6.4 [string::insert] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 21.3.6.4 [string::insert], paragraph 4, contains the following,
-"Then throws length_error if size() &gt;= npos - rlen."
-</p>
-
-<p>
-Related to DR 83, this sentence should probably be removed.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p><p>This requirement is redundant but correct. No change is
-needed.</p>
-
-
-
-
-<hr>
-<h3><a name="378"></a>378. locale immutability and locale::operator=()</h3>
-<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a></p>
-<p><b>Discussion:</b></p>
-<p>
-I think there is a problem with 22.1.1, p6 which says that
-</p>
-<pre> -6- An instance of locale is immutable; once a facet reference
- is obtained from it, that reference remains usable as long
- as the locale value itself exists.
-</pre>
-<p>
-and 22.1.1.2, p4:
-</p>
-<pre> const locale&amp; operator=(const locale&amp; other) throw();
-
- -4- Effects: Creates a copy of other, replacing the current value.
-</pre>
-<p>
-How can a reference to a facet obtained from a locale object remain
-valid after an assignment that clearly must replace all the facets
-in the locale object? Imagine a program such as this
-</p>
-<pre> std::locale loc ("de_DE");
- const std::ctype&lt;char&gt; &amp;r0 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
- loc = std::locale ("en_US");
- const std::ctype&lt;char&gt; &amp;r1 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
-</pre>
-<p>
-Is r0 really supposed to be preserved and destroyed only when loc goes
-out of scope?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p><i>[Summer '04 mid-meeting mailing: Martin and Dietmar believe this
- is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a> and recommend that it be
- closed.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="385"></a>385. Does call by value imply the CopyConstructible requirement?</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-10-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Many function templates have parameters that are passed by value;
-a typical example is <tt>find_if</tt>'s <i>pred</i> parameter in
-25.1.5 [alg.find]. Are the corresponding template parameters
-(<tt>Predicate</tt> in this case) implicitly required to be
-CopyConstructible, or does that need to be spelled out explicitly?
-</p>
-
-<p>
-This isn't quite as silly a question as it might seem to be at first
-sight. If you call <tt>find_if</tt> in such a way that template
-argument deduction applies, then of course you'll get call by value
-and you need to provide a copy constructor. If you explicitly provide
-the template arguments, however, you can force call by reference by
-writing something like <tt>find_if&lt;my_iterator,
-my_predicate&amp;&gt;</tt>. The question is whether implementation
-are required to accept this, or whether this is ill-formed because
-my_predicate&amp; is not CopyConstructible.
-</p>
-
-<p>
-The scope of this problem, if it is a problem, is unknown. Function
-object arguments to generic algorithms in clauses 25 [algorithms]
-and 26 [numerics] are obvious examples. A review of the whole
-library is necessary.
-</p>
-<p><i>[
-This is really two issues. First, predicates are typically passed by
-value but we don't say they must be Copy Constructible. They should
-be. Second: is specialization allowed to transform value arguments
-into references? References aren't copy constructible, so this should
-not be allowed.
-]</i></p>
-
-<p><i>[
-2007-01-12, Howard: First, despite the note above, references <b>are</b>
-copy constructible. They just aren't assignable. Second, this is very
-closely related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> and should be consistent with that.
-That issue already says that implementations are allowed to copy
-function objects. If one passes in a reference, it is copyable, but
-susceptible to slicing if one passes in a reference to a base. Third,
-with rvalue reference in the language one only needs to satisfy
-MoveConstructible to pass an rvalue "by value". Though the function
-might still copy the function object internally (requiring
-CopyConstructible). Finally (and fwiw), if we wanted to, it is easy to
-code all of the std::algorithms such that they do not copy function
-objects internally. One merely passes them by reference internally if
-desired (this has been fully implemented and shipped for several years).
- If this were mandated, it would reverse <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, allowing
-function objects to reliably maintain state. E.g. the example in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a> would reliably remove only the third element.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Recommend NAD.
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Generic algorithms will be marked with concepts and these will imply a requirement
-of MoveConstructible (not CopyConstructible). The signature of the function will
-then precisely describe and enforce the precise requirements.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="388"></a>388. Use of complex as a key in associative containers</h3>
-<p><b>Section:</b> 26.3 [complex.numbers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.numbers">issues</a> in [complex.numbers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Practice with std::complex&lt;&gt; and the associative containers
-occasionally reveals artificial and distracting issues with constructs
-resembling: std::set&lt;std::complex&lt;double&gt; &gt; s;
-</p>
-
-<p>
-The main reason for the above to fail is the absence of an approriate
-definition for std::less&lt;std::complex&lt;T&gt; &gt;. That in turn comes from
-the definition of the primary template std::less&lt;&gt; in terms of
-operator&lt;.
-</p>
-
-<p>
-The usual argument goes as follows: Since there is no ordering over
-the complex field compatible with field operations it makes little
-sense to define a function operator&lt; operating on the datatype
-std::complex&lt;T&gt;. That is fine. However, that reasoning does not carry
-over to std::less&lt;T&gt; which is used, among other things, by associative
-containers as an ordering useful to meet complexity requirements.
-</p>
-
-<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</p>
-
-<p><i>[
-Pre Bellevue: Reopened at the request of Alisdair.
-]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-This is a request for a design change, and not a defect in the standard.
-It is in scope to consider, but the group feels that it is not a change
-that we need to do. Is there a total ordering for floating point values,
-including NaN? There is not a clear enough solution or big enough
-problem for us to solve. Solving this problem would require solving the
-problem for floating point, which is equally unclear. The LWG noted that
-users who want to put objects into an associative container for which
-operator&lt; isn't defined can simply provide their own comparison function
-object. NAD
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Informally: Add a specialization of std::less for std::complex.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Discussed in Santa Cruz. An overwhelming majority of the LWG
-believes this should not be treated a DR: it's a request for a design
-change, not a defect in the existing standard. Most people (10-3)
-believed that we probably don't want this change, period: as with
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, it's hard to know where to draw the line.
-The LWG noted that users who want to put objects into an associative
-container for which <tt>operator&lt;</tt> isn't defined can simply
-provide their own comparison function object.</p>
-
-
-
-
-
-<hr>
-<h3><a name="390"></a>390. CopyConstructible requirements too strict</h3>
-<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Doug Gregor <b>Date:</b> 2002-10-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The CopyConstructible requirements in Table 30 state that for an
-object t of type T (where T is CopyConstructible), the expression &amp;t
-returns the address of t (with type T*). This requirement is overly
-strict, in that it disallows types that overload operator&amp; to not
-return a value of type T*. This occurs, for instance, in the <a href="http://www.boost.org/libs/lambda">Boost.Lambda</a> library, where
-operator&amp; is overloaded for a Boost.Lambda function object to return
-another function object.
-</p>
-
-<p>Example:</p>
-
-<pre> std::vector&lt;int&gt; u, v;
- int x;
- // ...
- std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
-</pre>
-
-<p>
-_1 * x returns an unnamed function object with operator&amp; overloaded to
-not return T* , therefore rendering the std::transform call ill-formed.
-However, most standard library implementations will compile this code
-properly, and the viability of such binder libraries is severely hindered
-by the unnecessary restriction in the CopyConstructible requirements.
-</p>
-
-<p>
-For reference, the address of an object can be retrieved without using
-the address-of operator with the following function template:
-</p>
-
-<pre> template &lt;typename T&gt; T* addressof(T&amp; v)
- {
- return reinterpret_cast&lt;T*&gt;(
- &amp;const_cast&lt;char&amp;&gt;(reinterpret_cast&lt;const volatile char &amp;&gt;(v)));
- }
-</pre>
-
-<p>
-Note: this relates directly to library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, which
-will need to be reexamined if the CopyConstructible requirements
-change.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove the last two rows of Table 30, eliminating the requirements
-that &amp;t and &amp;u return the address of t and u, respectively.
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This was a deliberate design decision. Perhaps it should be
- reconsidered for C++0x. </p>
-
-
-
-
-
-<hr>
-<h3><a name="392"></a>392. 'equivalence' for input iterators</h3>
-<p><b>Section:</b> 24.1.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Corwin Joy <b>Date:</b> 2002-12-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-In section 24.1.1 [input.iterators] table 72 -
-'Input Iterator Requirements' we have as a postcondition of *a:
-"If a==b and (a, b) is in the domain of == then *a is equivalent to *b".
-</p>
-
-<p>
-In section 24.5.3.5 [istreambuf.iterator::equal] it states that
-"istreambuf_iterator::equal returns true if and only if both iterators
-are at end-of-stream, or neither is at end-of-stream, <i>regardless of
-what streambuf object they use</i>." (My emphasis).
-</p>
-
-<p>
-The defect is that either 'equivalent' needs to be more precisely
-defined or the conditions for equality in 24.5.3.5 [istreambuf.iterator::equal]
-are incorrect. (Or both).
-</p>
-
-<p>Consider the following example:</p>
-<pre> #include &lt;iostream&gt;
- #include &lt;fstream&gt;
- #include &lt;iterator&gt;
- using namespace std;
-
- int main() {
- ifstream file1("file1.txt"), file2("file2.txt");
- istreambuf_iterator&lt;char&gt; f1(file1), f2(file2);
- cout &lt;&lt; "f1 == f2 : " &lt;&lt; boolalpha &lt;&lt; (f1 == f2) &lt;&lt; endl;
- cout &lt;&lt; "f1 = " &lt;&lt; *f1 &lt;&lt; endl;
- cout &lt;&lt; "f2 = " &lt;&lt; *f2 &lt;&lt; endl;
- return 0;
- }
-</pre>
-
-<p>Now assuming that neither f1 or f2 are at the end-of-stream then
-f1 == f2 by 24.5.3.5 [istreambuf.iterator::equal].</p>
-
-<p>However, it is unlikely that *f1 will give the same value as *f2 except
-by accident.</p>
-
-<p>So what does *f1 'equivalent' to *f2 mean? I think the standard should
-be clearer on this point, or at least be explicit that this does not
-mean that *f1 and *f2 are required to have the same value in the case
-of input iterators.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p><p>The two iterators aer not in the domain of ==</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="393"></a>393. do_in/do_out operation on state unclear</h3>
-<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Alberto Barbati <b>Date:</b> 2002-12-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-this DR follows the discussion on the previous thread "codecvt::do_in
-not consuming external characters". It's just a clarification issue
-and not a request for a change.
-</p>
-<p>
-Can do_in()/do_out() produce output characters without consuming input
-characters as a result of operation on state?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a note at the end of 22.2.1.4.2 [locale.codecvt.virtuals],
-paragraph 3:
-</p>
-
-<p>
-[Note: As a result of operations on state, it can return ok or partial
-and set from_next == from and to_next != to. --end note]
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-The submitter believes that standard already provides an affirmative
-answer to the question. However, the current wording has induced a few
-library implementors to make the incorrect assumption that
-do_in()/do_out() always consume at least one internal character when
-they succeed.
-</p>
-
-<p>
-The submitter also believes that the proposed resolution is not in
-conflict with the related issue 76. Moreover, by explicitly allowing
-operations on state to produce characters, a codecvt implementation
-may effectively implement N-to-M translations without violating the
-"one character at a time" principle described in such issue. On a side
-note, the footnote in the proposed resolution of issue 76 that
-informally rules out N-to-M translations for basic_filebuf should be
-removed if this issue is accepted as valid.
-</p>
-
-
-<p><i>[
-Kona (2007): The proposed resolution is to add a note. Since this is
-non-normative, the issue is editorial, but we believe that the note is
-correct. Proposed Disposition: NAD, Editorial
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="399"></a>399. volations of unformatted input function requirements</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-01-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-The Effects clauses for the two functions below violate the
-general requirements on unformatted input functions outlined
-in 27.6.1.3: they do not begin by constructing a sentry object.
-Instead, they begin by calling widen ('\n'), which may throw
-an exception. The exception is then allowed to propagate from
-the unformatted input function irrespective of the setting of
-exceptions().
- </p>
- <p>
-Note that in light of 27.6.1.1, p3 and p4, the fact that the
-functions allow exceptions thrown from widen() to propagate
-may not strictly speaking be a defect (but the fact that the
-functions do not start by constructing a sentry object still
-is). However, since an exception thrown from ctype&lt;charT&gt;
-::widen() during any other input operation (say, from within
-a call to num_get&lt;charT&gt;::get()) will be caught and cause
-badbit to be set, these two functions should not be treated
-differently for the sake of consistency.
- </p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Not a defect. The standard is consistent, and the behavior required
-by the standard is unambiguous. Yes, it's theoretically possible for
-widen to throw. (Not that this will happen for the default ctype
-facet or for most real-world replacement ctype facets.) Users who
-define ctype facets that can throw, and who care about this behavior,
-can use alternative signatures that don't call widen.
-</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="424"></a>424. normative notes</h3>
-<p><b>Section:</b> 17.3.1.1 [structure.summary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-The text in 17.3.1.1, p1 says:
-<br>
-
-"Paragraphs labelled "Note(s):" or "Example(s):" are informative, other
-paragraphs are normative."
-<br>
-
-The library section makes heavy use of paragraphs labeled "Notes(s),"
-some of which are clearly intended to be normative (see list 1), while
-some others are not (see list 2). There are also those where the intent
-is not so clear (see list 3).
-<br><br>
-
-List 1 -- Examples of (presumably) normative Notes:
-<br>
-
-20.7.5.1 [allocator.members], p3,<br>
-20.7.5.1 [allocator.members], p10,<br>
-21.3.2 [string.cons], p11,<br>
-22.1.1.2 [locale.cons], p11,<br>
-23.2.2.3 [deque.modifiers], p2,<br>
-25.3.7 [alg.min.max], p3,<br>
-26.3.6 [complex.ops], p15,<br>
-27.5.2.4.3 [streambuf.virt.get], p7.<br>
-<br>
-
-List 2 -- Examples of (presumably) informative Notes:
-<br>
-
-18.5.1.3 [new.delete.placement], p3,<br>
-21.3.6.6 [string::replace], p14,<br>
-22.2.1.4.2 [locale.codecvt.virtuals], p3,<br>
-25.1.4 [alg.foreach], p4,<br>
-26.3.5 [complex.member.ops], p1,<br>
-27.4.2.5 [ios.base.storage], p6.<br>
-<br>
-
-List 3 -- Examples of Notes that are not clearly either normative
-or informative:
-<br>
-
-22.1.1.2 [locale.cons], p8,<br>
-22.1.1.5 [locale.statics], p6,<br>
-27.5.2.4.5 [streambuf.virt.put], p4.<br>
-<br>
-
-None of these lists is meant to be exhaustive.
-</p>
-
-<p><i>[Definitely a real problem. The big problem is there's material
- that doesn't quite fit any of the named paragraph categories
- (e.g. <b>Effects</b>). Either we need a new kind of named
- paragraph, or we need to put more material in unnamed paragraphs
- jsut after the signature. We need to talk to the Project Editor
- about how to do this.
-]</i></p>
-
-
-<p><i>[
-Bellevue: Specifics of list 3: First 2 items correct in std (22.1.1.2,
-22.1.1.5) Third item should be non-normative (27.5.2.4.5), which Pete
-will handle editorially.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p><i>[Pete: I changed the paragraphs marked "Note" and "Notes" to use "Remark" and "Remarks".
-Fixed as editorial. This change has been in the WD since the post-Redmond mailing, in 2004.
-Recommend NAD.]</i></p>
-
-<p><i>[
-Batavia: We feel that the references in List 2 above should be changed from <i>Remarks</i>
-to <i>Notes</i>. We also feel that those items in List 3 need to be double checked for
-the same change. Alan and Pete to review.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="429"></a>429. typo in basic_ios::clear(iostate)</h3>
-<p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a></p>
-<p><b>Discussion:</b></p>
- <p>
-
-The Effects clause in 27.4.4.3, p5 describing the effects of a call to
-the ios_base member function clear(iostate state) says that the function
-only throws if the respective bits are already set prior to the function
-call. That's obviously not the intent. If it was, a call to clear(badbit)
-on an object for which (rdstate() == goodbit &amp;&amp; exceptions() == badbit)
-holds would not result in an exception being thrown.
-
- </p>
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-The text ought to be changed from
-<br>
-
-"If (rdstate() &amp; exceptions()) == 0, returns. ..."
-<br>
-
-to
-<br>
-
-"If (state &amp; exceptions()) == 0, returns. ..."
- </p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="433"></a>433. Contradiction in specification of unexpected()</h3>
-<p><b>Section:</b> 18.7.2.4 [unexpected] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Vyatcheslav Sysoltsev <b>Date:</b> 2003-09-29</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Clause 15.5.2 [except.unexpected] paragraph 1 says that "void unexpected();
-is called (18.7.2) immediately after completing the stack unwinding
-for the former function", but 18.7.2.4 (Effects) says that "void
-unexpected(); . . . Calls the unexpected_handler function in effect
-immediately after evaluating the throwexpression (18.7.2.2),". Isn't
-here a contradiction: 15.5.2 requires stack have been unwound when in
-void unexpected() and therefore in unexpected_handler but 18.7.2.4
-claims that unexpected_handler is called "in effect immediately" after
-evaluation of throw expression is finished, so there is no space left
-for stack to be unwound therefore? I think the phrase "in effect
-immediately" should be removed from the standard because it brings
-ambiguity in understanding.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>There is no contradiction. The phrase "in effect immediately" is
- just to clarify which handler is to be called.</p>
-
-
-
-
-
-<hr>
-<h3><a name="437"></a>437. Formatted output of function pointers is confusing</h3>
-<p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Ivan Godard <b>Date:</b> 2003-10-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Given:
-</p>
-<pre>void f(int) {}
-void(*g)(int) = f;
-cout &lt;&lt; g;
-</pre>
-
-<p>
-(with the expected #include and usings), the value printed is a rather
-surprising "true". Rather useless too.
-</p>
-
-<p>The standard defines:</p>
-
-<pre>ostream&amp; operator&lt;&lt;(ostream&amp;, void*);</pre>
-
-<p>which picks up all data pointers and prints their hex value, but does
-not pick up function pointers because there is no default conversion
-from function pointer to void*. Absent that, we fall back to legacy
-conversions from C and the function pointer is converted to bool.
-</p>
-
-<p>There should be an analogous inserter that prints the address of a
- function pointer.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>This is indeed a wart, but there is no good way to solve it. C
- doesn't provide a portable way of outputting the address of a
- function point either.</p>
-
-
-
-
-
-<hr>
-<h3><a name="439"></a>439. Should facets be copyable?</h3>
-<p><b>Section:</b> 22.2 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-11-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The following facets classes have no copy constructors described in
- the standard, which, according to the standard, means that they are
- supposed to use the compiler-generated defaults. Default copy
- behavior is probably inappropriate. We should either make these
- classes uncopyable or else specify exactly what their constructors do.</p>
-
-<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#421">421</a>.</p>
-
-<pre> ctype_base
- ctype
- ctype_byname
- ctype&lt;char&gt;
- ctype_byname&lt;char&gt;
- codecvt_base
- codecvt
- codecvt_byname
- num_get
- num_put
- numpunct
- numpunct_byname
- collate
- collate_byname
- time_base
- time_get
- time_get_byname
- time_put
- time_put_byname
- money_get
- money_put
- money_base
- moneypunct
- moneypunct_byname
- messages_base
- messages
- messages_byname
-</pre>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>The copy constructor in the base class is private.</p>
-
-
-
-
-
-<hr>
-<h3><a name="440"></a>440. Should std::complex use unqualified transcendentals?</h3>
-<p><b>Section:</b> 26.3.8 [complex.transcendentals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-11-05</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Operations like <tt>pow</tt> and <tt>exp</tt> on
-<tt>complex&lt;T&gt;</tt> are typically implemented in terms of
-operations like <tt>sin</tt> and <tt>cos</tt> on <tt>T</tt>.
-Should implementations write this as <tt>std::sin</tt>, or as plain
-unqualified <tt>sin</tt>?
-</p>
-
-<p>The issue, of course, is whether we want to use
-argument-dependent lookup in the case where <tt>T</tt> is a
-user-defined type. This is similar to the issue of valarray
-transcendentals, as discussed in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>.</p>
-
-<p>This issue differs from valarray transcendentals in two important
-ways. First, "the effect of instantiating the template
-<tt>complex</tt> for types other than float, double or long double is
-unspecified." (26.3.1 [complex.synopsis]) Second, the standard does not
-dictate implementation, so there is no guarantee that a particular
-real math function is used in the implementation of a particular
-complex function.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>If you instantiate std::complex for user-defined types, all bets
-are off.</p>
-
-
-
-
-
-<hr>
-<h3><a name="447"></a>447. Wrong template argument for time facets</h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2003-12-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a></p>
-<p><b>Discussion:</b></p>
-<p>
-22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others:
-</p>
-<pre> time_get&lt;char,InputIterator&gt;
- time_get_byname&lt;char,InputIterator&gt;
- time_get&lt;wchar_t,OutputIterator&gt;
- time_get_byname&lt;wchar_t,OutputIterator&gt;
-</pre>
-
-<p>
-The second argument to the last two should be InputIterator, not
-OutputIterator.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the second template argument to InputIterator.
-</p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="450"></a>450. set::find is inconsistent with associative container requirements</h3>
-<p><b>Section:</b> 23.3.3 [set] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#set">issues</a> in [set].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a></p>
-<p><b>Discussion:</b></p>
-<p>map/multimap have:</p>
-
-<pre> iterator find(const key_type&amp; x) const;
- const_iterator find(const key_type&amp; x) const;
-</pre>
-
-<p>
-which is consistent with the table of associative container requirements.
-But set/multiset have:
-</p>
-<pre> iterator find(const key_type&amp;) const;
-</pre>
-
-<p>
-set/multiset should look like map/multimap, and honor the requirements
-table, in this regard.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="451"></a>451. Associative erase should return an iterator</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts], 23.3 [associative] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a></p>
-<p><b>Discussion:</b></p>
-<p>map/multimap/set/multiset have:</p>
-<pre> void erase(iterator);
- void erase(iterator, iterator);
-</pre>
-
-<p>But there's no good reason why these can't return an iterator, as for
-vector/deque/list:</p>
-<pre> iterator erase(iterator);
- iterator erase(iterator, iterator);
-</pre>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Informally: The table of associative container requirements, and the
-relevant template classes, should return an iterator designating the
-first element beyond the erased subrange.
-</p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="452"></a>452. locale::combine should be permitted to generate a named locale</h3>
-<p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<pre>template&lt;class Facet&gt;
- locale::combine(const locale&amp;) const;
-</pre>
-<p>
-is obliged to create a locale that has no name. This is overspecification
-and overkill. The resulting locale should follow the usual rules -- it
-has a name if the locale argument has a name and Facet is one of the
-standard facets.
-</p>
-
-<p><i>[
- Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440,
- c++std-lib-13443): agreed that it's overkill to say that the locale
- is obligated to be nameless. However, we also can't require it to
- have a name. At the moment, locale names are based on categories
- and not on individual facets. If a locale contains two different
- facets of different names from the same category, then this would
- not fit into existing naming schemes. We need to give
- implementations more freedom. Bill will provide wording.
-]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>After further discussion the LWG decided to close this as NAD.
- The fundamental problem is that names right now are per-category,
- not per-facet. The <tt>combine</tt> member function works at the
- wrong level of granularity.</p>
-
-
-
-
-
-<hr>
-<h3><a name="462"></a>462. Destroying objects with static storage duration</h3>
-<p><b>Section:</b> 3.6.3 [basic.start.term], 18.3 [cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-03-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-3.6.3 Termination spells out in detail the interleaving of static
-destructor calls and calls to functions registered with atexit. To
-match this behavior requires intimate cooperation between the code
-that calls destructors and the exit/atexit machinery. The former
-is tied tightly to the compiler; the latter is a primitive mechanism
-inherited from C that traditionally has nothing to do with static
-construction and destruction. The benefits of intermixing destructor
-calls with atexit handler calls is questionable at best, and <i>very</i>
-difficult to get right, particularly when mixing third-party C++
-libraries with different third-party C++ compilers and C libraries
-supplied by still other parties.
-</p>
-
-<p>
-I believe the right thing to do is defer all static destruction
-until after all atexit handlers are called. This is a change in
-behavior, but one that is likely visible only to perverse test
-suites. At the very least, we should <i>permit</i> deferred destruction
-even if we don't require it.
-</p>
-
-<p><i>[If this is to be changed, it should probably be changed by CWG.
- At this point, however, the LWG is leaning toward NAD. Implementing
- what the standard says is hard work, but it's not impossible and
- most vendors went through that pain years ago. Changing this
- behavior would be a user-visible change, and would break at least
- one real application.]</i></p>
-
-
-<p><i>[
-Batavia: Send to core with our recommendation that we should permit deferred
-destruction but not require it.
-]</i></p>
-
-
-<p><i>[
-Howard: The course of action recommended in Batavia would undo LWG
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a> and break current code implementing the "phoenix
-singleton". Search the net for "phoenix singleton atexit" to get a feel
-for the size of the adverse impact this change would have. Below is
-sample code which implements the phoenix singleton and would break if
-<tt>atexit</tt> is changed in this way:
-]</i></p>
-
-
-<blockquote><pre>#include &lt;cstdlib&gt;
-#include &lt;iostream&gt;
-#include &lt;type_traits&gt;
-#include &lt;new&gt;
-
-class A
-{
- bool alive_;
- A(const A&amp;);
- A&amp; operator=(const A&amp;);
-public:
- A() : alive_(true) {std::cout &lt;&lt; "A()\n";}
- ~A() {alive_ = false; std::cout &lt;&lt; "~A()\n";}
- void use()
- {
- if (alive_)
- std::cout &lt;&lt; "A is alive\n";
- else
- std::cout &lt;&lt; "A is dead\n";
- }
-};
-
-void deallocate_resource();
-
-// This is the phoenix singleton pattern
-A&amp; get_resource(bool create = true)
-{
- static std::aligned_storage&lt;sizeof(A), std::alignment_of&lt;A&gt;::value&gt;::type buf;
- static A* a;
- if (create)
- {
- if (a != (A*)&amp;buf)
- {
- a = ::new (&amp;buf) A;
- std::atexit(deallocate_resource);
- }
- }
- else
- {
- a-&gt;~A();
- a = (A*)&amp;buf + 1;
- }
- return *a;
-}
-
-void deallocate_resource()
-{
- get_resource(false);
-}
-
-void use_A(const char* message)
-{
- A&amp; a = get_resource();
- std::cout &lt;&lt; "Using A " &lt;&lt; message &lt;&lt; "\n";
- a.use();
-}
-
-struct B
-{
- ~B() {use_A("from ~B()");}
-};
-
-B b;
-
-int main()
-{
- use_A("from main()");
-}
-</pre></blockquote>
-
-<p>
-The correct output is:
-</p>
-
-<blockquote><pre>A()
-Using A from main()
-A is alive
-~A()
-A()
-Using A from ~B()
-A is alive
-~A()
-</pre></blockquote>
-
-<p><i>[
-Bellevue: Confirmed no interaction with <tt>quick_exit</tt>.
-Strong feeling against mandating the change. Leaning towards NAD rather than permitting the change,
-as this would make common implementations of pheonix-singleton pattern implementation defined, as noted by Howard.
-Bill agrees issue is no longer serious, and accepts NAD.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="466"></a>466. basic_string ctor should prevent null pointer error</h3>
-<p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Daniel Frey <b>Date:</b> 2004-06-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Today, my colleagues and me wasted a lot of time. After some time, I
-found the problem. It could be reduced to the following short example:
-</p>
-
-<pre> #include &lt;string&gt;
- int main() { std::string( 0 ); }
-</pre>
-
-<p>The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and
-Comeau online) compile the above without errors or warnings! The
-programs (at least for the GCC) resulted in a SEGV.</p>
-
-<p>I know that the standard explicitly states that the ctor of string
-requires a char* which is not zero. STLs could easily detect the above
-case with a private ctor for basic_string which takes a single 'int'
-argument. This would catch the above code at compile time and would not
-ambiguate any other legal ctors.</p>
-
-<p><i>[Redmond: No great enthusiasm for doing this. If we do,
- however, we want to do it for all places that take <tt>charT*</tt>
- pointers, not just the single-argument constructor. The other
- question is whether we want to catch this at compile time (in which
- case we catch the error of a literal 0, but not an expression whose
- value is a null pointer), at run time, or both.]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD. Relegate this functionality to debugging implementations.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="470"></a>470. accessing containers from their elements' special functions</h3>
-<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-The standard doesn't prohibit the destructors (or any other special
-functions) of containers' elements invoked from a member function
-of the container from "recursively" calling the same (or any other)
-member function on the same container object, potentially while the
-container is in an intermediate state, or even changing the state
-of the container object while it is being modified. This may result
-in some surprising (i.e., undefined) behavior.
-</p>
-
-<p>Read email thread starting with c++std-lib-13637 for more.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Add to Container Requirements the following new paragraph:</p>
-
-<pre> Unless otherwise specified, the behavior of a program that
- invokes a container member function f from a member function
- g of the container's value_type on a container object c that
- called g from its mutating member function h, is undefined.
- I.e., if v is an element of c, directly or indirectly calling
- c.h() from v.g() called from c.f(), is undefined.
-</pre>
-
-<p><i>[Redmond: This is a real issue, but it's probably a clause 17
- issue, not clause 23. We get the same issue, for example, if we
- try to destroy a stream from one of the stream's callback functions.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD. We agree this is an issue, but not a defect.
-We believe that there is no wording we can put in the standard
-that will cover all cases without introducing unfortunate
-corner cases.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="472"></a>472. Missing "Returns" clause in std::equal_range</h3>
-<p><b>Section:</b> 25.3.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Prateek R Karandikar <b>Date:</b> 2004-06-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#equal.range">issues</a> in [equal.range].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a></p>
-<p><b>Discussion:</b></p>
-<p>
-There is no "Returns:" clause for std::equal_range, which returns non-void.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>Fixed as part of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>.</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="476"></a>476. Forward Iterator implied mutability</h3>
-<p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>24.1/3 says:</p>
-<blockquote><p>
- Forward iterators satisfy all the requirements of the input and
- output iterators and can be used whenever either kind is specified
-</p></blockquote>
-
-<p>
-The problem is that satisfying the requirements of output iterator
-means that you can always assign *something* into the result of
-dereferencing it. That makes almost all non-mutable forward
-iterators non-conforming. I think we need to sever the refinement
-relationship between forward iterator and output iterator.
-</p>
-
-<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>. But this is not a dup.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>Yes, 24.1/3 does say that. But it's introductory material. The
-precise specification is in 24.1.3, and the requrements table there is
-right. We don't need to fine-tune introductory wording. (Especially
-since this wording is likely to be changed as part of the iterator
-overhaul.)</p>
-
-
-
-
-
-<hr>
-<h3><a name="477"></a>477. Operator-&gt; for const forward iterators</h3>
-<p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
-<p><b>Discussion:</b></p>
-<p>
-The Forward Iterator requirements table contains the following:
-</p>
-<pre> expression return type operational precondition
- semantics
- ========== ================== =========== ==========================
- a-&gt;m U&amp; if X is mutable, (*a).m pre: (*a).m is well-defined.
- otherwise const U&amp;
-
- r-&gt;m U&amp; (*r).m pre: (*r).m is well-defined.
-</pre>
-
-<p>
-The first line is exactly right. The second line is wrong. Basically
-it implies that the const-ness of the iterator affects the const-ness
-of referenced members. But Paragraph 11 of [lib.iterator.requirements] says:
-</p>
-
-<blockquote><p>
- In the following sections, a and b denote values of type const X, n
- denotes a value of the difference type Distance, u, tmp, and m
- denote identifiers, r denotes a value of X&amp;, t denotes a value of
- value type T, o denotes a value of some type that is writable to
- the output iterator.
-</p></blockquote>
-
-<p>AFAICT if we need the second line at all, it should read the same
-as the first line.</p>
-
-<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG agrees that this is a real problem. Marked as a DUP
- because the LWG chose to adopt the solution proposed in
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="479"></a>479. Container requirements and placement new</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Herb Sutter <b>Date:</b> 2004-08-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a></p>
-<p><b>Discussion:</b></p>
-<p>Nothing in the standard appears to make this program ill-formed:</p>
-
-<pre> struct C {
- void* operator new( size_t s ) { return ::operator new( s ); }
- // NOTE: this hides in-place and nothrow new
- };
-
- int main() {
- vector&lt;C&gt; v;
- v.push_back( C() );
- }
-</pre>
-
-<p>Is that intentional? We should clarify whether or not we intended
- to require containers to support types that define their own special
- versions of <tt>operator new</tt>.</p>
-
-<p><i>[
-Lillehammer: A container will definitely never use this overridden
-operator new, but whether it will fail to compile is unclear from the
-standard. Are containers supposed to use qualified or unqualified
-placement new? 20.4.1.1 is somewhat relevant, but the standard
-doesn't make it completely clear whether containers have to use
-Allocator::construct(). If containers don't use it, the details of how
-containers use placement new are unspecified. That is the real bug,
-but it needs to be fixed as part of the allocator overhaul. Weak
-support that the eventual solution should make this code well formed.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="480"></a>480. unary_function and binary_function should have protected nonvirtual destructors</h3>
-<p><b>Section:</b> 20.6.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2004-08-19</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The classes std::unary_function and std::binary_function are both
-designed to be inherited from but contain no virtual functions. This
-makes it too easy for a novice programmer to write code like
-binary_function&lt;int, int, int&gt; *p = new plus&lt;int&gt;; delete p;</p>
-
-<p>There are two common ways to prevent this source of undefined
-behavior: give the base class a public virtual destructor, or give it
-a protected nonvirtual destructor. Since unary_function and
-binary_function have no other virtual functions, (note in particular
-the absence of an operator()() ), it would cost too much to give them
-public virtual destructors. Therefore, they should be given protected
-nonvirtual destructors.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change Paragraph 20.3.1 of the Standard from</p>
-<pre> template &lt;class Arg, class Result&gt;
- struct unary_function {
- typedef Arg argument_type;
- typedef Result result_type;
- };
-
- template &lt;class Arg1, class Arg2, class Result&gt;
- struct binary_function {
- typedef Arg1 first_argument_type;
- typedef Arg2 second_argument_type;
- typedef Result result_type;
- };
-</pre>
-
-<p>to</p>
-<pre> template &lt;class Arg, class Result&gt;
- struct unary_function {
- typedef Arg argument_type;
- typedef Result result_type;
- protected:
- ~unary_function() {}
- };
-
- template &lt;class Arg1, class Arg2, class Result&gt;
- struct binary_function {
- typedef Arg1 first_argument_type;
- typedef Arg2 second_argument_type;
- typedef Result result_type;
- protected:
- ~binary_function() {}
- };
-</pre>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG doesn't believe the existing definition causes anybody any
- concrete harm.</p>
-
-
-
-
-
-<hr>
-<h3><a name="481"></a>481. unique's effects on the range [result, last)</h3>
-<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2004-08-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The standard says that unique(first, last) "eliminates all but the
-first element from every consecutive group of equal elements" in
-[first, last) and returns "the end of the resulting range". So a
-postcondition is that [first, result) is the same as the old [first,
-last) except that duplicates have been eliminated.
-</p>
-
-<p>What postconditions are there on the range [result, last)? One
- might argue that the standard says nothing about those values, so
- they can be anything. One might also argue that the standard
- doesn't permit those values to be changed, so they must not be.
- Should the standard say something explicit one way or the other?</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>We don't want to make many guarantees about what's in [result,
-end). Maybe we aren't being quite explicit enough about not being
-explicit, but it's hard to think that's a major problem.</p>
-
-
-
-
-
-<hr>
-<h3><a name="482"></a>482. Swapping pairs</h3>
-<p><b>Section:</b> 20.2.3 [pairs], 20.4 [tuple] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2004-09-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>(Based on recent comp.std.c++ discussion)</p>
-
-<p>Pair (and tuple) should specialize std::swap to work in terms of
-std::swap on their components. For example, there's no obvious reason
-why swapping two objects of type pair&lt;vector&lt;int&gt;,
-list&lt;double&gt; &gt; should not take O(1).</p>
-
-<p><i>[Lillehammer: We agree it should be swappable. Howard will
- provide wording.]</i></p>
-
-
-<p><i>[
-Post Oxford: We got <tt>swap</tt> for <tt>pair</tt> but accidently
-missed <tt>tuple</tt>. <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Wording provided in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
-</p>
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD, fixed by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.2.3%20-%20Pairs">N1856</a>.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="483"></a>483. Heterogeneous equality and EqualityComparable</h3>
-<p><b>Section:</b> 25.1 [alg.nonmodifying], 25.2 [alg.modifying.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2004-09-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a></p>
-<p><b>Discussion:</b></p>
-<p>c++std-lib-14262</p>
-
-<p>[lib.alg.find] requires T to be EqualityComparable:</p>
-
-<pre>template &lt;class InputIterator, class T&gt;
- InputIterator find(InputIterator first, InputIterator last,
- const T&amp; value);
-</pre>
-
-<p>
-However the condition being tested, as specified in the Effects
-clause, is actually *i == value, where i is an InputIterator.
-</p>
-
-<p>
-The two clauses are in agreement only if the type of *i is T, but this
-isn't necessarily the case. *i may have a heterogeneous comparison
-operator that takes a T, or a T may be convertible to the type of *i.
-</p>
-
-<p>Further discussion (c++std-lib-14264): this problem affects a
- number of algorithsm in clause 25, not just <tt>find</tt>. We
- should try to resolve this problem everywhere it appears.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>[lib.alg.find]:</p>
-<blockquote><p>
- Remove [lib.alg.find]/1.
-</p></blockquote>
-
-<p>[lib.alg.count]:</p>
-<blockquote><p>
- Remove [lib.alg.count]/1.
-</p></blockquote>
-
-<p>[lib.alg.search]:</p>
-<blockquote><p>
- Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4.
-</p></blockquote>
-
-<p>[lib.alg.replace]:</p>
-
-<blockquote>
- <p>
- Remove [lib.alg.replace]/1.
- Replace [lb.alg.replace]/2 with:
- </p>
-
- <blockquote><p>
- For every iterator i in the range [first, last) for which *i == value
- or pred(*i) holds perform *i = new_value.
- </p></blockquote>
-
- <p>
- Remove the first sentence of /4.
- Replace the beginning of /5 with:
- </p>
-
- <blockquote><p>
- For every iterator i in the range [result, result + (last -
- first)), assign to *i either...
- </p></blockquote>
-
- <p>(Note the defect here, current text says assign to i, not *i).</p>
-</blockquote>
-
-<p>[lib.alg.fill]:</p>
-
-<blockquote>
- <p>
- Remove "Type T is Assignable (23.1), " from /1.
- Replace /2 with:
- </p>
-
- <blockquote><p>
- For every iterator i in the range [first, last) or [first, first + n),
- perform *i = value.
- </p></blockquote>
-</blockquote>
-
-<p>[lib.alg.remove]:</p>
-<blockquote><p>
- Remove /1.
- Remove the first sentence of /6.
-</p></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>Duplicate of (a subset of) issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>.</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="486"></a>486. min/max CopyConstructible requirement is too strict</h3>
-<p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-10-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a></p>
-<p><b>Discussion:</b></p>
-<p>A straightforward implementation of these algorithms does not need to
-copy T.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>drop the the words "and CopyConstructible" from paragraphs 1 and 4</p>
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="487"></a>487. Allocator::construct is too limiting</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Dhruv Matani <b>Date:</b> 2004-10-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The standard's version of allocator::construct(pointer,
-const_reference) severely limits what you can construct using this
-function. Say you can construct a socket from a file descriptor. Now,
-using this syntax, I first have to manually construct a socket from
-the fd, and then pass the constructed socket to the construct()
-function so it will just to an uninitialized copy of the socket I
-manually constructed. Now it may not always be possible to copy
-construct a socket eh! So, I feel that the changes should go in the
-allocator::construct(), making it:
-</p>
-<pre> template&lt;typename T&gt;
- struct allocator{
- template&lt;typename T1&gt;
- void construct(pointer T1 const&amp; rt1);
- };
-</pre>
-
-<p>
-Now, the ctor of the class T which matches the one that takes a T1 can
-be called! Doesn't that sound great?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>NAD. STL uses copying all the time, and making it possible for
- allocators to construct noncopyable objects is useless in the
- absence of corresponding container changes. We might consider this
- as part of a larger redesign of STL.</p>
-
-
-
-
-
-<hr>
-<h3><a name="489"></a>489. std::remove / std::remove_if wrongly specified</h3>
-<p><b>Section:</b> 25.2.8 [alg.remove] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.remove">issues</a> in [alg.remove].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the
-behavior of the mutating sequence operations std::remove and
-std::remove_if. However, the wording does not reflect the intended
-behavior [Note: See definition of intended behavior below] of these
-algorithms, as it is known to the C++ community [1].
-</p>
-
-
-
-<p>1) Analysis of current wording:</p>
-
-
-<p>25.2.7 [lib.alg.remove], paragraph 2:</p>
-
-<p>Current wording says:
-"Effects: Eliminates all the elements referred to by iterator i in the
-range [first, last) for which the following corresponding conditions
-hold: *i == value, pred(*i) != false."</p>
-
-<p>
-This sentences expresses specifically that all elements denoted by the
-(original) range [first, last) for which the corresponding condition
-hold will be eliminated. Since there is no formal definition of the term
-"eliminate" provided, the meaning of "eliminate" in everyday language
-implies that as postcondition, no element in the range denoted by
-[first, last) will hold the corresponding condition on reiteration over
-the range [first, last).
-</p>
-
-<p>
-However, this is neither the intent [Note: See definition of intended
-behavior below] nor a general possible approach. It can be easily proven
-that if all elements of the original range[first, last) will hold the
-condition, it is not possible to substitute them by an element for which
-the condition will not hold.
-</p>
-
-
-<p>25.2.7 [lib.alg.remove], paragraph 3:</p>
-
-<p>
-Current wording says:
-"Returns: The end of the resulting range."
-</p>
-
-<p>
-The resulting range is not specified. In combination with 25.2.7
-[lib.alg.remove], paragraph 2, the only reasonable interpretation of
-this so-called resulting range is the range [first,last) - thus
-returning always the ForwardIterator 'last' parameter.
-</p>
-
-
-<p>
-25.2.7 [lib.alg.remove], paragraph 4:
-</p>
-
-<p>
-Current wording says:
-"Notes: Stable: the relative order of the elements that are not removed
-is the same as their relative order in the original range"
-</p>
-
-<p>
-This sentences makes use of the term "removed", which is neither
-specified, nor used in a previous paragraph (which uses the term
-"eliminate"), nor unamgiuously separated from the name of the algorithm.
-</p>
-
-
-<p>2) Description of intended behavior:</p>
-
-<p>
-For the rest of this Defect Report, it is assumed that the intended
-behavior was that all elements of the range [first, last) which do not
-hold the condition *i == value (std::remove) or pred(*i) != false
-(std::remove_if)], call them s-elements [Note: s...stay], will be placed
-into a contiguous subrange of [first, last), denoted by the iterators
-[first, return value). The number of elements in the resulting range
-[first, return value) shall be equal to the number of s-elements in the
-original range [first, last). The relative order of the elements in the
-resulting subrange[first, return value) shall be the same as the
-relative order of the corresponding elements in the original range. It
-is undefined whether any elements in the resulting subrange [return
-value, last) will hold the corresponding condition, or not.
-</p>
-
-<p>
-All implementations known to the author of this Defect Report comply
-with this intent. Since the intent of the behavior (contrary to the
-current wording) is also described in various utility references serving
-the C++ community [1], it is not expected that fixing the paragraphs
-will influence current code - unless the code relies on the behavior as
-it is described by current wording and the implementation indeed
-reflects the current wording, and not the intent.
-</p>
-
-
-
-<p>3) Proposed fixes:</p>
-
-
-<p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p>
-
-<p>
-"Effect: Places all the elements referred to by iterator i in the range
-[first, last) for which the following corresponding conditions hold :
-!(*i == value), pred(*i) == false into the subrange [first, k) of the
-original range, where k shall denote a value of type ForwardIterator. It
-is undefined whether any elements in the resulting subrange [k, last)
-will hold the corresponding condition, or not."
-</p>
-
-<p>Comments to the new wording:</p>
-
-<p>
-a) "Places" has no special meaning, and the everyday language meaning
-should fit.
-b) The corresponding conditions were negated compared to the current
-wording, becaue the new wording requires it.
-c) The wording "of the original range" might be redundant, since any
-subrange starting at 'first' and containing no more elements than the
-original range is implicitly a subrange of the original range [first,
-last).
-d) The iterator k was introduced instead of "return value" in order to
-avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall
-denote a value of type ForwardIterator" might be redundant, because it
-follows implicitly by 25.2.7/3.
-e) "Places" does, in the author's opinion, explicitly forbid duplicating
-any element holding the corresponding condition in the original range
-[first, last) within the resulting range [first, k). If there is doubt
-this term might be not unambiguous regarding this, it is suggested that
-k is specified more closely by the following wording: "k shall denote a
-value of type ForwardIterator [Note: see d)] so that k - first is equal
-to the number of elements in the original range [first, last) for which
-the corresponding condition did hold". This could also be expressed as a
-separate paragraph "Postcondition:"
-f) The senctence "It is undefined whether any elements in the resulting
-subrange [k, last) will hold the corresponding condition, or not." was
-added consciously so the term "Places" does not imply if the original
-range [first, last) contains n elements holding the corresponding
-condition, the identical range[first, last) will also contain exactly n
-elements holding the corresponding condition after application of the
-algorithm.
-</p>
-
-<p>
-Change 25.2.7 [lib.alg.remove], paragraph 3 to:
-
-"Returns: The iterator k."
-</p>
-
-<p>
-Change 25.2.7 [lib.alg.remove], paragraph 4 to:
-
-"Notes: Stable: the relative order of the elements that are placed into
-the subrange [first, return value) shall be the same as their relative
-order was in the original range [first, last) prior to application of
-the algorithm."
-</p>
-
-<p>
-Comments to the new wording:
-</p>
-
-<p>
-a) the wording "was ... prior to application of the algorithm" is used
-to explicitly distinguish the original range not only by means of
-iterators, but also by a 'chronological' factor from the resulting range
-[first, return value). It might be redundant.
-</p>
-
-<p>
-[1]:
-The wording of these references is not always unambiguous, and provided
-examples partially contradict verbal description of the algorithms,
-because the verbal description resembles the problematic wording of
-ISO/IEC 14882:2003.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes that the standard is sufficiently clear, and that
- there is no evidence of any real-world confusion about this point.</p>
-
-
-
-
-
-<hr>
-<h3><a name="490"></a>490. std::unique wrongly specified</h3>
-<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the
-behavior of the mutating sequence operation std::unique. However, the
-wording does not reflect the intended behavior [Note: See definition of
-intended behavior below] of these algorithms, as it is known to the C++
-community [1].</p>
-
-
-
-<p>1) Analysis of current wording:</p>
-
-
-<p>25.2.8 [lib.alg.unique], paragraph 1:</p>
-
-<p>
-Current wording says:
-"Effects: Eliminates all but the first element from every consecutive
-group of equal elements referred to by the iterator i in the range
-[first, last) for which the following corresponding conditions hold: *i
-== *(i - 1) or pred(*i, *(i -1)) != false"
-</p>
-
-<p>
-This sentences expresses specifically that all elements denoted by the
-(original) range [first, last) which are not but the first element from
-a consecutive group of equal elements (where equality is defined as *i
-== *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call
-them r-elements [Note: r...remove], will be eliminated. Since there is
-no formal definition of the term "eliminate" provided, it is undefined
-how this "elimination" takes place. But the meaning of "eliminate" in
-everyday language seems to disallow explicitly that after application of
-the algorithm, any r-element will remain at any position of the range
-[first, last) [2].
-</p>
-
-<p>
-Another defect in the current wording concerns the iterators used to
-compare two elements for equality: The current wording contains the
-expression "(i - 1)", which is not covered by 25/9 [Note: See DR
-submitted by Thomas Mang regarding invalid iterator arithmetic
-expressions].
-</p>
-
-
-<p>
-25.2.8 [lib.alg.unique], paragraph 2:
-</p>
-<p>Current wording says:
-"Returns: The end of the resulting range."</p>
-
-<p>
-The resulting range is not specified. In combination with 25.2.8
-[lib.alg.unique], paragraph 1, one reasonable interpretation (in the
-author's opinion even the only possible interpretation) of this
-so-called resulting range is the range [first, last) - thus returning
-always the ForwardIterator 'last' parameter.
-</p>
-
-<p>2) Description of intended behavior:</p>
-
-<p>
-For the rest of this Defect Report, it is assumed that the intended
-behavior was that all elements denoted by the original range [first,
-last) which are the first element from a consecutive group of elements
-for which the corresponding conditions: *(i-1) == *i (for the version of
-unique without a predicate argument) or pred(*(i-1), *i) ! = false (for
-the version of unique with a predicate argument) [Note: If such a group
-of elements consists of only a single element, this is also considered
-the first element] [Note: See resolutions of DR 202], call them
-s-elements [Note: s...stay], will be placed into a contiguous subrange
-of [first, last), denoted by the iterators [first, return value). The
-number of elements in the resulting range [first, return value) shall be
-equal to the number of s-elements in the original range [first, last).
-Invalid iterator arithmetic expressions are expected to be resolved as
-proposed in DR submitted by Thomas Mang regarding invalid iterator
-arithmetic expressions. It is also assumed by the author that the
-relative order of the elements in the resulting subrange [first, return
-value) shall be the same as the relative order of the corresponding
-elements (the s-elements) in the original range [Note: If this was not
-intended behavior, the additional proposed paragraph about stable order
-will certainly become obsolete].
-Furthermore, the resolutions of DR 202 are partially considered.
-</p>
-
-<p>
-All implementations known to the author of this Defect Report comply
-with this intent [Note: Except possible effects of DR 202]. Since this
-intent of the behavior (contrary to the current wording) is also
-described in various utility references serving the C++ community [1],
-it is not expected that fixing the paragraphs will influence current
-code [Note: Except possible effects of DR 202] - unless the code relies
-on the behavior as it is described by current wording and the
-implementation indeed reflects the current wording, and not the intent.
-</p>
-
-
-
-<p>3) Proposed fixes:</p>
-
-<p>
-Change 25.2.8 [lib.alg.unique], paragraph 1 to:
-</p>
-
-<p>
-"Effect: Places the first element from every consecutive group of
-elements, referred to by the iterator i in the range [first, last), for
-which the following conditions hold: *(i-1) == *i (for the version of
-unique without a predicate argument) or pred(*(i -1), *i) != false (for
-the version of unique with a predicate argument), into the subrange
-[first, k) of the original range, where k shall denote a value of type
-ForwardIterator."
-</p>
-
-<p>Comments to the new wording:</p>
-
-<p>
-a) The new wording was influenced by the resolutions of DR 202. If DR
-202 is resolved in another way, the proposed wording need also
-additional review.
-b) "Places" has no special meaning, and the everyday language meaning
-should fit.
-c) The expression "(i - 1)" was left, but is expected that DR submitted
-by Thomas Mang regarding invalid iterator arithmetic expressions will
-take this into account.
-d) The wording "(for the version of unique without a predicate
-argument)" and "(for the version of unique with a predicate argument)"
-was added consciously for clarity and is in resemblence with current
-23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant.
-e) The wording "of the original range" might be redundant, since any
-subrange starting at first and containing no more elements than the
-original range is implicitly a subrange of the original range [first,
-last).
-f) The iterator k was introduced instead of "return value" in order to
-avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The
-wording ", where k shall denote a value of type ForwardIterator" might
-be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique],
-paragraph 2.
-g) "Places" does, in the author's opinion, explicitly forbid duplicating
-any s-element in the original range [first, last) within the resulting
-range [first, k). If there is doubt this term might be not unambiguous
-regarding this, it is suggested that k is specified more closely by the
-following wording: "k shall denote a value of type ForwardIterator
-[Note: See f)] so that k - first is equal to the number of elements in
-the original range [first, last) being the first element from every
-consecutive group of elements for which the corresponding condition did
-hold". This could also be expressed as a separate paragraph
-"Postcondition:".
-h) If it is considered that the wording is unclear whether it declares
-the element of a group which consists of only a single element
-implicitly to be the first element of this group [Note: Such an
-interpretation could eventually arise especially in case last - first ==
-1] , the following additional sentence is proposed: "If such a group of
-elements consists of only a single element, this element is also
-considered the first element."
-</p>
-
-<p>
-Change 25.2.8 [lib.alg.unique], paragraph 2 to:
-"Returns: The iterator k."
-</p>
-
-<p>
-Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph
-2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8
-[lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if
-the preceding expressions are used, or the preceding expressions shall
-be eliminated if wording inside {} is used):
-</p>
-
-<p>
-"Notes:{Postcondition:} Stable: the relative order of the elements that
-are placed into the subrange [first, return value {k}) shall be the same
-as their relative order was in the original range [first, last) prior to
-application of the algorithm."
-</p>
-
-<p>Comments to the new wording:</p>
-
-<p>
-a) It is assumed by the author that the algorithm was intended to be
-stable.
-In case this was not the intent, this paragraph becomes certainly
-obsolete.
-b) The wording "was ... prior to application of the algorithm" is used
-to explicitly distinguish the original range not only by means of
-iterators, but also by a 'chronological' factor from the resulting range
-[first, return value). It might be redundant.
-</p>
-
-<p>
-25.2.8 [lib.alg.unique], paragraph 3:
-</p>
-<p>See DR 239.</p>
-
-<p>
-4) References to other DRs:
-</p>
-
-<p>
-See DR 202, but which does not address any of the problems described in
-this Defect Report [Note: This DR is supposed to complement DR 202].
-See DR 239.
-See DR submitted by Thomas Mang regarding invalid iterator arithmetic
-expressions.
-</p>
-
-<p>
-[1]:
-The wording of these references is not always unambiguous, and provided
-examples partially contradict verbal description of the algorithms,
-because the verbal description resembles the problematic wording of
-ISO/IEC 14882:2003.
-</p>
-
-<p>
-[2]:
-Illustration of conforming implementations according to current wording:
-</p>
-
-<p>
-One way the author of this DR considers how this "elimination" could be
-achieved by a conforming implementation according to current wording is
-by substituting each r-element by _any_ s-element [Note: s...stay; any
-non-r-element], since all r-elements are "eliminated".
-</p>
-
-<p>
-In case of a sequence consisting of elements being all 'equal' [Note:
-See DR 202], substituting each r-element by the single s-element is the
-only possible solution according to current wording.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes the standard is sufficiently clear. No
-implementers get it wrong, and changing it wouldn't cause any code to
-change, so there is no real-world harm here.</p>
-
-
-
-
-
-<hr>
-<h3><a name="491"></a>491. std::list&lt;&gt;::unique incorrectly specified</h3>
-<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Thomas Mang <b>Date:</b> 2004-12-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In Section 23.2.4.4 [list.ops], paragraphs 19 to 21 describe the
-behavior of the std::list&lt;T, Allocator&gt;::unique operation. However, the
-current wording is defective for various reasons.</p>
-
-
-
-<p>
-1) Analysis of current wording:
-</p>
-
-<p>23.2.4.4 [list.ops], paragraph 19:</p>
-
-<p>
-Current wording says:
-"Effects: Eliminates all but the first element from every consecutive
-group of equal elements referred to by the iterator i in the range
-[first + 1, last) for which *i == *(i - 1) (for the version of unique
-with no argument) or pred(*i, *(i -1)) (for the version of unique with a
-predicate argument) holds."</p>
-
-<p>
-This sentences makes use of the undefined term "Eliminates". Although it
-is, to a certain degree, reasonable to consider the term "eliminate"
-synonymous with "erase", using "Erase" in the first place, as the
-wording of 23.2.4.4 [list.ops], paragraph 15 does, would be clearer.</p>
-
-<p>
-The range of the elements referred to by iterator i is "[first + 1,
-last)". However, neither "first" nor "last" is defined.</p>
-
-<p>
-The sentence makes three times use of iterator arithmetic expressions (
-"first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not
-defined for bidirectional iterator [see DR submitted by Thomas Mang
-regarding invalid iterator arithmetic expressions].</p>
-
-<p>
-The same problems as pointed out in DR 202 (equivalence relation / order
-of arguments for pred()) apply to this paragraph.</p>
-
-<p>
-23.2.4.4 [list.ops], paragraph 20:
-</p>
-
-<p>
-Current wording says:
-"Throws: Nothing unless an exception in thrown by *i == *(i-1) or
-pred(*i, *(i - 1))"</p>
-
-<p>
-The sentence makes two times use of invalid iterator arithmetic
-expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
-</p>
-<p>
-[Note: Minor typos: "in" / missing dot at end of sentence.]
-</p>
-
-<p>
-23.2.4.4 [list.ops], paragraph 21:</p>
-
-<p>
-Current wording says:
-"Complexity: If the range (last - first) is not empty, exactly (last -
-first) - 1 applications of the corresponding predicate, otherwise no
-application of the predicate.</p>
-
-<p>
-See DR 315 regarding "(last - first)" not yielding a range.</p>
-
-<p>
-Invalid iterator arithmetic expression "(last - first) - 1" left .</p>
-
-
-<p>2) Description of intended behavior:</p>
-
-<p>
-For the rest of this Defect Report, it is assumed that "eliminate" is
-supposed to be synonymous to "erase", that "first" is equivalent to an
-iterator obtained by a call to begin(), "last" is equivalent to an
-iterator obtained by a call to end(), and that all invalid iterator
-arithmetic expressions are resolved as described in DR submitted by
-Thomas Mang regarding invalid iterator arithmetic expressions.</p>
-
-<p>
-Furthermore, the resolutions of DR 202 are considered regarding
-equivalence relation and order of arguments for a call to pred.</p>
-
-<p>
-All implementations known to the author of this Defect Report comply
-with these assumptions, apart from the impact of the alternative
-resolution of DR 202. Except for the changes implied by the resolutions
-of DR 202, no impact on current code is expected.</p>
-
-<p>
-3) Proposed fixes:</p>
-
-<p>
-Change 23.2.4.4 [list.ops], paragraph 19 to:</p>
-
-<p>
-"Effect: Erases all but the first element from every consecutive group
-of elements, referred to by the iterator i in the range [begin(),
-end()), for which the following conditions hold: *(i-1) == *i (for the
-version of unique with no argument) or pred(*(i-1), *i) != false (for
-the version of unique with a predicate argument)."</p>
-
-<p>
-Comments to the new wording:</p>
-
-<p>
-a) The new wording was influenced by DR 202 and the resolutions
-presented there. If DR 202 is resolved in another way, the proposed
-wording need also additional review.
-b) "Erases" refers in the author's opinion unambiguously to the member
-function "erase". In case there is doubt this might not be unamgibuous,
-a direct reference to the member function "erase" is suggested [Note:
-This would also imply a change of 23.2.4.4 [list.ops], paragraph
-15.].
-c) The expression "(i - 1)" was left, but is expected that DR submitted
-by Thomas Mang regarding invalid iterator arithmetic expressions will
-take this into account.
-d) The wording "(for the version of unique with no argument)" and "(for
-the version of unique with a predicate argument)" was kept consciously
-for clarity.
-e) "begin()" substitutes "first", and "end()" substitutes "last". The
-range need adjustment from "[first + 1, last)" to "[begin(), end())" to
-ensure a valid range in case of an empty list.
-f) If it is considered that the wording is unclear whether it declares
-the element of a group which consists of only a single element
-implicitly to be the first element of this group [Note: Such an
-interpretation could eventually arise especially in case size() == 1] ,
-the following additional sentence is proposed: "If such a group of
-elements consists of only a single element, this element is also
-considered the first element."</p>
-
-<p>
-Change 23.2.4.4 [list.ops], paragraph 20 to:</p>
-
-<p>
-"Throws: Nothing unless an exception is thrown by *(i-1) == *i or
-pred(*(i-1), *i)."</p>
-
-<p>
-Comments to the new wording:</p>
-
-<p>
-a) The wording regarding the conditions is identical to proposed
-23.2.4.4 [list.ops], paragraph 19. If 23.2.4.4 [list.ops],
-paragraph 19 is resolved in another way, the proposed wording need also
-additional review.
-b) The expression "(i - 1)" was left, but is expected that DR submitted
-by Thomas Mang regarding invalid iterator arithmetic expressions will
-take this into account.
-c) Typos fixed.</p>
-
-<p>
-Change 23.2.4.4 [list.ops], paragraph 21 to:</p>
-
-<p>
-"Complexity: If empty() == false, exactly size() - 1 applications of the
-corresponding predicate, otherwise no applications of the corresponding
-predicate."</p>
-
-<p>
-Comments to the new wording:</p>
-
-<p>
-a) The new wording is supposed to also replace the proposed resolution
-of DR 315, which suffers from the problem of undefined "first" / "last".
-</p>
-
-<p>
-5) References to other DRs:</p>
-
-<p>See DR 202.
-See DR 239.
-See DR 315.
-See DR submitted by Thomas Mang regarding invalid iterator arithmetic
-expressions.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>"All implementations known to the author of this Defect Report
-comply with these assumption", and "no impact on current code is
-expected", i.e. there is no evidence of real-world confusion or
-harm.</p>
-
-
-
-
-
-<hr>
-<h3><a name="493"></a>493. Undefined Expression in Input Iterator Note Title</h3>
-<p><b>Section:</b> 24.1.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2004-12-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>1) In 24.1.1/3, the following text is currently present.</p>
-
-<p>"Note: For input iterators, a==b does not imply ++a=++b (Equality does
-not guarantee the substitution property or referential transparency)."</p>
-
-<p>However, when in Table 72, part of the definition of ++r is given as:</p>
-
-<p>"pre: r is dereferenceable.
-post: any copies of the previous value of r are no longer required
-either to be dereferenceable ..."</p>
-
-<p>While a==b does not imply that b is a copy of a, this statement should
-perhaps still be made more clear.</p>
-
-<p>2) There are no changes to intended behaviour</p>
-
-<p>
-3) This Note should be altered to say "Note: For input iterators a==b,
-when its behaviour is defined ++a==++b may still be false (Equality does
-not guarantee the substitution property or referential transparency).</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>This is descriptive text, not normative, and the meaning is clear.</p>
-
-
-
-
-
-<hr>
-<h3><a name="494"></a>494. Wrong runtime complexity for associative container's insert and delete</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Hans B os <b>Date:</b> 2004-12-19</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>According to [lib.associative.reqmts] table 69, the runtime comlexity
-of insert(p, t) and erase(q) can be done in amortized constant time.</p>
-
-<p>It was my understanding that an associative container could be
-implemented as a balanced binary tree.</p>
-
-<p>For inser(p, t), you 'll have to iterate to p's next node to see if t
-can be placed next to p. Furthermore, the insertion usually takes
-place at leaf nodes. An insert next to the root node will be done at
-the left of the root next node</p>
-
-<p>So when p is the root node you 'll have to iterate from the root to
-its next node, which takes O(log(size)) time in a balanced tree.</p>
-
-<p>If you insert all values with insert(root, t) (where root is the
-root of the tree before insertion) then each insert takes O(log(size))
-time. The amortized complexity per insertion will be O(log(size))
-also.</p>
-
-<p>For erase(q), the normal algorithm for deleting a node that has no
-empty left or right subtree, is to iterate to the next (or previous),
-which is a leaf node. Then exchange the node with the next and delete
-the leaf node. Furthermore according to DR 130, erase should return
-the next node of the node erased. Thus erasing the root node,
-requires iterating to the next node.</p>
-
-<p>Now if you empty a map by deleting the root node until the map is
-empty, each operation will take O(log(size)), and the amortized
-complexity is still O(log(size)).</p>
-
-<p>The operations can be done in amortized constant time if iterating
-to the next node can be done in (non amortized) constant time. This
-can be done by putting all nodes in a double linked list. This
-requires two extra links per node. To me this is a bit overkill since
-you can already efficiently insert or erase ranges with erase(first,
-last) and insert(first, last).</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>Only "amortized constant" in special circumstances, and we believe
- that's implementable. That is: doing this N times will be O(N), not
- O(log N).</p>
-
-
-
-
-
-<hr>
-<h3><a name="499"></a>499. Std. doesn't seem to require stable_sort() to be stable!</h3>
-<p><b>Section:</b> 25.3.1.2 [stable.sort] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Prateek Karandikar <b>Date:</b> 2005-04-12</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<blockquote><p>
-17.3.1.1 Summary</p>
-
-<p>
-1 The Summary provides a synopsis of the category, and introduces the
-first-level subclauses. Each subclause also provides a summary, listing
-the headers specified in the subclause and the library entities
-provided in each header.
-</p>
-<p>
-2 Paragraphs labelled "Note(s):" or "Example(s):" are informative,
-other paragraphs are normative.
-</p></blockquote>
-
-<p>So this means that a "Notes" paragraph wouldn't be normative. </p>
-
-<blockquote><p>
-25.3.1.2 stable_sort
-</p>
-<pre>template&lt;class RandomAccessIterator&gt;
-void stable_sort(RandomAccessIterat or first, RandomAccessIterator last);
-
-template&lt;class RandomAccessIterator, class Compare&gt;
-void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
-</pre>
-<p>
-1 Effects: Sorts the elements in the range [first, last).
-</p>
-<p>
-2 Complexity: It does at most N(log N)^2 (where N == last - first)
-comparisons; if enough extra memory is available, it is N log N.
-</p>
-<p>
-3 Notes: Stable: the relative order of the equivalent elements is
-preserved.
-</p></blockquote>
-
-<p>
-The Notes para is informative, and nowhere else is stability mentioned above.
-</p>
-
-<p>
-Also, I just searched for the word "stable" in my copy of the Standard.
-and the phrase "Notes: Stable: the relative order of the elements..."
-is repeated several times in the Standard library clauses for
-describing various functions. How is it that stability is talked about
-in the informative paragraph? Or am I missing something obvious?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-This change has already been made.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="500"></a>500. do_length cannot be implemented correctly</h3>
-<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Krzysztof &#379;elechowski <b>Date:</b> 2005-05-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<ol>
-<li>codecvt::do_length is of type int;</li>
-<li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li>
-<li>ptrdiff_t cannot be cast to an int without data loss.</li>
-</ol>
-<p>
-Contradiction.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="501"></a>501. Proposal: strengthen guarantees of lib.comparisons</h3>
-<p><b>Section:</b> 20.6.3 [base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Me &lt;anti_spam_email2003@yahoo.com&gt; <b>Date:</b> 2005-06-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#base">issues</a> in [base].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<blockquote><p>
-"For templates greater, less, greater_equal, and less_equal,
-the specializations for any pointer type yield a total order, even if
-the built-in operators &lt;, &gt;, &lt;=, &gt;= do not."
-</p></blockquote>
-
-<p>
-The standard should do much better than guarantee that these provide a
-total order, it should guarantee that it can be used to test if memory
-overlaps, i.e. write a portable memmove. You can imagine a platform
-where the built-in operators use a uint32_t comparison (this tests for
-overlap on this platform) but the less&lt;T*&gt; functor is allowed to be
-defined to use a int32_t comparison. On this platform, if you use
-std::less with the intent of making a portable memmove, comparison on
-an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give
-incorrect results.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a footnote to 20.5.3/8 saying:
-</p>
-
-<blockquote><p>
-Given a p1 and p2 such that p1 points to N objects of type T and p2
-points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M),
-less returns the same value when comparing all pointers in [p1,p1+N) to
-all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R
-such that less returns the same value when comparing all pointers in
-[p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when
-comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M).
-For the sake of completeness, the null pointer value (4.10) for T is
-considered to be an array of 1 object that doesn't overlap with any
-non-null pointer to T. less_equal, greater, greater_equal, equal_to,
-and not_equal_to give the expected results based on the total ordering
-semantics of less. For T of void, treat it as having similar semantics
-as T of char i.e. less&lt;cv T*&gt;(a, b) gives the same results as less&lt;cv
-void*&gt;(a, b) which gives the same results as less&lt;cv char*&gt;((cv
-char*)(cv void*)a, (cv char*)(cv void*)b).
-</p></blockquote>
-
-<p>
-I'm also thinking there should be a footnote to 20.5.3/1 saying that if
-A and B are similar types (4.4/4), comp&lt;A&gt;(a,b) returns the same value
-as comp&lt;B&gt;(a,b) (where comp is less, less_equal, etc.). But this might
-be problematic if there is some really funky operator overloading going
-on that does different things based on cv (that should be undefined
-behavior if somebody does that though). This at least should be
-guaranteed for all POD types (especially pointers) that use the
-built-in comparison operators.
-</p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-less is already required to provide a strict weak ordering which is good enough
-to detect overlapping memory situations.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="504"></a>504. Integer types in pseudo-random number engine requirements</h3>
-<p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type,
-g is an ... object returning values of unsigned integral type ..."
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 5.1.1 [tr.rand.req], Paragraph 2 replace
-</p>
-
-<blockquote><p>
-... s is a value of integral type, g is an lvalue of a type other than X that
-defines a zero-argument function object returning values of <del>unsigned integral</del> type
-<ins><tt>unsigned long int</tt></ins>,
-...
-</p></blockquote>
-
-<p>
-In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
-</p>
-
-<blockquote><p>
-creates an engine with the initial internal state
-determined by <ins><tt>static_cast&lt;unsigned long&gt;(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
-</p></blockquote>
-
-<p><i>[
-Mont Tremblant: Both s and g should be unsigned long.
-This should refer to the constructor signatures. Jens provided wording post Mont Tremblant.
-]</i></p>
-
-
-<p><i>[
-Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved
-to Ready.
-]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Jens: Just requiring X(unsigned long) still makes it possible
-for an evil library writer to also supply a X(int) that does something
-unexpected. The wording above requires that X(s) always performs
-as if X(unsigned long) would have been called. I believe that is
-sufficient and implements our intentions from Mont Tremblant. I
-see no additional use in actually requiring a X(unsigned long)
-signature. u.seed(s) is covered by its reference to X(s), same
-arguments.
-</p>
-
-
-<p><i>[
-Portland: Subsumed by N2111.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="506"></a>506. Requirements of Distribution parameter for variate_generator</h3>
-<p><b>Section:</b> 26.4 [rand], TR1 5.1.3 [tr.rand.var] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Paragraph 3 requires that template argument U (which corresponds to template
-parameter Engine) satisfy all uniform random number generator requirements.
-However, there is no analogous requirement regarding the template argument
-that corresponds to template parameter Distribution. We believe there should
-be, and that it should require that this template argument satisfy all random
-distribution requirements.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18.
-</p>
-<p>
-Consequence 2: Add max() and min() functions to those distributions that
-do not already have them.
-</p>
-
-<p><i>[
-Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere.
-Marc supports having min and max to satisfy generic programming interface.
-]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>Berlin: N1932 makes this moot: variate_generator has been eliminated.</p>
-
-
-
-
-
-<hr>
-<h3><a name="509"></a>509. Uniform_int template parameters</h3>
-<p><b>Section:</b> 26.4.8.1 [rand.dist.uni], TR1 5.1.7.1 [tr.rand.dist.iunif] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.uni">issues</a> in [rand.dist.uni].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In [tr.rand.dist.iunif] the uniform_int distribution currently has a single
-template parameter, IntType, used as the input_type and as the result_type
-of the distribution. We believe there is no reason to conflate these types
-in this way.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-We recommend that there be a second template parameter to
-reflect the distribution's input_type, and that the existing first template
-parameter continue to reflect (solely) the result_type:
-</p>
-<blockquote><pre>template&lt; class IntType = int, UIntType = unsigned int &gt;
-class uniform_int
-{
-public:
- // types
- typedef UIntType input_type;
- typedef IntType result_type;
-</pre></blockquote>
-
-<p><i>[
-Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been
-eliminated.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="510"></a>510. Input_type for bernoulli_distribution</h3>
-<p><b>Section:</b> 26.4.8.2 [rand.dist.bern], TR1 5.1.7.2 [tr.rand.dist.bern] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In [tr.rand.dist.bern] the distribution currently requires;
-</p>
-<blockquote><pre>typedef int input_type;
-</pre></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-We believe this is an unfortunate choice, and recommend instead:
-</p>
-<blockquote><pre>typedef unsigned int input_type;
-</pre></blockquote>
-
-<p><i>[
-Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been
-eliminated.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="511"></a>511. Input_type for binomial_distribution</h3>
-<p><b>Section:</b> 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Unlike all other distributions in TR1, this binomial_distribution has an
-implementation-defined input_type. We believe this is an unfortunate choice,
-because it hinders users from writing portable code. It also hinders the
-writing of compliance tests. We recommend instead:
-</p>
-<blockquote><pre>typedef RealType input_type;
-</pre></blockquote>
-<p>
-While this choice is somewhat arbitrary (as it was for some of the other
-distributions), we make this particular choice because (unlike all other
-distributions) otherwise this template would not publish its RealType
-argument and so users could not write generic code that accessed this
-second template parameter. In this respect, the choice is consistent with
-the other distributions in TR1.
-</p>
-<p>
-We have two reasons for recommending that a real type be specified instead.
-One reason is based specifically on characteristics of binomial distribution
-implementations, while the other is based on mathematical characteristics of
-probability distribution functions in general.
-</p>
-<p>
-Implementations of binomial distributions commonly use Stirling approximations
-for values in certain ranges. It is far more natural to use real values to
-represent these approximations than it would be to use integral values to do
-so. In other ranges, implementations reply on the Bernoulli distribution to
-obtain values. While TR1's bernoulli_distribution::input_type is specified as
-int, we believe this would be better specified as double.
-</p>
-<p>
-This brings us to our main point: The notion of a random distribution rests
-on the notion of a cumulative distribution function, which in turn mathematically
-depends on a continuous dependent variable. Indeed, such a distribution function
-would be meaningless if it depended on discrete values such as integers - and this
-remains true even if the distribution function were to take discrete steps.
-</p>
-<p>
-Although this note is specifically about binomial_distribution::input_type,
-we intend to recommend that all of the random distributions input_types be
-specified as a real type (either a RealType template parameter, or double,
-as appropriate).
-</p>
-<p>
-Of the nine distributions in TR1, four already have this characteristic
-(uniform_real, exponential_distribution, normal_distribution, and
-gamma_distribution). We have already argued the case for the binomial the
-remaining four distributions.
-</p>
-<p>
-In the case of uniform_int, we believe that the calculations to produce an
-integer result in a specified range from an integer in a different specified
-range is best done using real arithmetic. This is because it involves a
-product, one of whose terms is the ratio of the extents of the two ranges.
-Without real arithmetic, the results become less uniform: some numbers become
-more (or less) probable that they should be. This is, of course, undesireable
-behavior in a uniform distribution.
-</p>
-<p>
-Finally, we believe that in the case of the bernoulli_distribution (briefly
-mentioned earlier), as well as the cases of the geometric_distribution and the
-poisson_distribution, it would be far more natural to have a real input_type.
-This is because the most natural computation involves the random number
-delivered and the distribution's parameter p (in the case of bernoulli_distribution,
-for example, the computation is a comparison against p), and p is already specified
-in each case as having some real type.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<blockquote><pre>typedef RealType input_type;
-</pre></blockquote>
-
-<p><i>[
-Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been
-eliminated.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="512"></a>512. Seeding subtract_with_carry_01 from a single unsigned long</h3>
-<p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine
-is to be seeded given a single unsigned long. This algorithm is seriously
-flawed in the case where the engine parameter w (also known as word_size)
-exceeds 31 [bits]. The key part of the paragraph reads:
-</p>
-<blockquote><p>
-sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
-</p></blockquote>
-<p>
-and so forth.
-</p>
-<p>
-Since the specified linear congruential engine, lcg, delivers numbers with
-a maximum of 2147483563 (just a shade under 31 bits), then when w is, for
-example, 48, each of the x(i) will be less than 2**-17. The consequence
-is that roughly the first 400 numbers delivered will be conspicuously
-close to either zero or one.
-</p>
-<p>
-Unfortunately, this is not an innocuous flaw: One of the predefined engines
-in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit
-this poor behavior, while the original N1378 proposal states that these
-pre-defined engines are intended to be of "known good properties."
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for
-void seed(unsigned long value = 19780503) by
-</p>
-
-<blockquote><p>
-<i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any
-case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters
-<tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>,
-<tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del>
-sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) &#8230; x(-1)</tt>
-<ins>as if executing</ins></p>
-
-<blockquote><pre><ins>
-linear_congruential&lt;unsigned long, 40014, 0, 2147483563&gt; lcg(value);
-seed(lcg);
-</ins></pre></blockquote>
-
-<p>
-<del>to <tt>(<i>lcg</i>(1) 2<sup>-<i>w</i></sup>) mod 1
-&#8230; (<i>lcg</i>(<i>r</i>) 2<sup>-<i>w</i></sup>) mod 1</tt>,
-respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>,
-else sets carry<tt>(-1) = 0</tt>.</del></p>
-</blockquote>
-
-<p><i>[
-Jens provided revised wording post Mont Tremblant.
-]</i></p>
-
-
-<p><i>[
-Berlin: N1932 adopts the originally-proposed resolution of the issue.
-Jens's supplied wording is a clearer description of what is
-intended. Moved to Ready.
-]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Jens: I'm using an explicit type here, because fixing the
-prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a> even
-stricter) requirements we have for seed(Gen&amp;).
-</p>
-
-<p><i>[
-Portland: Subsumed by N2111.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="513"></a>513. Size of state for subtract_with_carry_01</h3>
-<p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Paragraph 3 begins:
-</p>
-<blockquote><p>
-The size of the state is r.
-</p></blockquote>
-<p>
-However, this is not quite consistent with the remainder of the paragraph
-which specifies a total of nr+1 items in the textual representation of
-the state. We recommend the sentence be corrected to match:
-</p>
-<blockquote><p>
-The size of the state is nr+1.
-</p></blockquote>
-<p>
-To give meaning to the coefficient n, it may be also desirable to move
-n's definition from later in the paragraph. Either of the following
-seem reasonable formulations:
-</p>
-<blockquote><p>
-With n=..., the size of the state is nr+1.
-</p></blockquote>
-<blockquote><p>
-The size of the state is nr+1, where n=... .
-</p></blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p><i>[
-Jens: I plead for "NAD" on the grounds that "size of state" is only
-used as an argument for big-O complexity notation, thus
-constant factors and additions don't count.
-]</i></p>
-
-
-<p><i>[
-Berlin: N1932 adopts the proposed NAD.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="514"></a>514. Size of state for subtract_with_carry</h3>
-<p><b>Section:</b> 26.4.3.3 [rand.eng.sub], TR1 5.1.4.3 [tr.rand.eng.sub] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Paragraph 2 begins:
-</p>
-<blockquote><p>
-The size of the state is r.
-</p></blockquote>
-<p>
-However, the next sentence specifies a total of r+1 items in the textual
-representation of the state, r specific x's as well as a specific carry.
-This makes a total of r+1 items that constitute the size of the state,
-rather than r.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-We recommend the sentence be corrected to match:
-</p>
-<blockquote><p>
- The size of the state is r+1.
-</p></blockquote>
-
-<p><i>[
-Jens: I plead for "NAD" on the grounds that "size of state" is only
-used as an argument for big-O complexity notation, thus
-constant factors and additions don't count.
-]</i></p>
-
-
-<p><i>[
-Berlin: N1932 adopts the proposed NAD.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="515"></a>515. Random number engine traits</h3>
-<p><b>Section:</b> 26.4.2 [rand.synopsis], TR1 5.1.2 [tr.rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-To accompany the concept of a pseudo-random number engine as defined in Table 17,
-we propose and recommend an adjunct template, engine_traits, to be declared in
-[tr.rand.synopsis] as:
-</p>
-<blockquote><pre>template&lt; class PSRE &gt;
-class engine_traits;
-</pre></blockquote>
-<p>
-This template's primary purpose would be as an aid to generic programming involving
-pseudo-random number engines. Given only the facilities described in tr1, it would
-be very difficult to produce any algorithms involving the notion of a generic engine.
-The intent of this proposal is to provide, via engine_traits&lt;&gt;, sufficient
-descriptive information to allow an algorithm to employ a pseudo-random number engine
-without regard to its exact type, i.e., as a template parameter.
-</p>
-<p>
-For example, today it is not possible to write an efficient generic function that
-requires any specific number of random bits. More specifically, consider a
-cryptographic application that internally needs 256 bits of randomness per call:
-</p>
-<blockquote><pre>template&lt; class Eng, class InIter, class OutIter &gt;
-void crypto( Eng&amp; e, InIter in, OutIter out );
-</pre></blockquote>
-<p>
-Without knowning the number of bits of randomness produced per call to a provided
-engine, the algorithm has no means of determining how many times to call the engine.
-</p>
-<p>
-In a new section [tr.rand.eng.traits], we proposed to define the engine_traits
-template as:
-</p>
-<blockquote><pre>template&lt; class PSRE &gt;
-class engine_traits
-{
- static std::size_t bits_of_randomness = 0u;
- static std::string name() { return "unknown_engine"; }
- // TODO: other traits here
-};
-</pre></blockquote>
-<p>
-Further, each engine described in [tr.rand.engine] would be accompanied by a
-complete specialization of this new engine_traits template.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p><i>[
-Berlin: Walter: While useful for implementation per TR1, N1932 has no need for this
-feature. Recommend close as NAD.
-]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1932.pdf">N1932</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
-covers this. Already in WP.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="516"></a>516. Seeding subtract_with_carry_01 using a generator</h3>
-<p><b>Section:</b> 26.4.3 [rand.eng], TR1 5.1.4.4 [tr.rand.eng.sub1] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng">issues</a> in [rand.eng].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Paragraph 6 says:
-</p>
-<blockquote><p>
-... obtained by successive invocations of g, ...
-</p></blockquote>
-<p>
-We recommend instead:
-</p>
-<blockquote><p>
-... obtained by taking successive invocations of g mod 2**32, ...
-</p></blockquote>
-<p>
-as the context seems to require only 32-bit quantities be used here.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7. Moved to Ready.
-</p>
-
-<p><i>[
-Portland: Subsumed by N2111.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="517"></a>517. Should include name in external representation</h3>
-<p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The last two rows of Table 16 deal with the i/o requirements of an engine,
-specifying that the textual representation of an engine's state,
-appropriately formatted, constitute the engine's external representation.
-</p>
-<p>
-This seems adequate when an engine's type is known. However, it seems
-inadequate in the context of generic code, where it becomes useful and
-perhaps even necessary to determine an engine's type via input.
-</p>
-<p>
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-We therefore recommend that, in each of these two rows of Table 16, the
-text "textual representation" be expanded so as to read "engine name
-followed by the textual representation."
-</p>
-
-<p><i>[
-Berlin: N1932 considers this NAD. This is a QOI issue.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="525"></a>525. type traits definitions not clear</h3>
-<p><b>Section:</b> 20.5.4 [meta.unary], TR1 4.5 [tr.meta.unary] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Robert Klarer <b>Date:</b> 2005-07-11</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It is not completely clear how the primary type traits deal with
-cv-qualified types. And several of the secondary type traits
-seem to be lacking a definition.
-</p>
-
-<p><i>[
-Berlin: Howard to provide wording.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Wording provided in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2028.html">N2028</a>.
-A
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
-provides more detail for motivation.
-</p>
-
-
-<p><b>Rationale:</b></p>
-Solved by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">revision (N2157)</a>
-in the WP.
-
-
-
-
-
-<hr>
-<h3><a name="526"></a>526. Is it undefined if a function in the standard changes in parameters?</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2005-09-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Problem: There are a number of places in the C++ standard library where
-it is possible to write what appear to be sensible ways of calling
-functions, but which can cause problems in some (or all)
-implementations, as they cause the values given to the function to be
-changed in a way not specified in standard (and therefore not coded to
-correctly work). These fall into two similar categories.
-</p>
-
-<p>
-1) Parameters taken by const reference can be changed during execution
-of the function
-</p>
-
-<p>
-Examples:
-</p>
-
-<p>
-Given std::vector&lt;int&gt; v:
-</p>
-<p>
-v.insert(v.begin(), v[2]);
-</p>
-<p>
-v[2] can be changed by moving elements of vector
-</p>
-
-
-<p>
-Given std::list&lt;int&gt; l:
-</p>
-<p>
-l.remove(*l.begin());
-</p>
-<p>
-Will delete the first element, and then continue trying to access it.
-This is particularily vicious, as it will appear to work in almost all
-cases.
-</p>
-
-<p>
-2) A range is given which changes during the execution of the function:
-Similarly,
-</p>
-
-<p>
-v.insert(v.begin(), v.begin()+4, v.begin()+6);
-</p>
-
-<p>
-This kind of problem has been partly covered in some cases. For example
-std::copy(first, last, result) states that result cannot be in the range
-[first, last). However, does this cover the case where result is a
-reverse_iterator built from some iterator in the range [first, last)?
-Also, std::copy would still break if result was reverse_iterator(last +
-1), yet this is not forbidden by the standard
-</p>
-
-<p>
-Solution:
-</p>
-
-<p>
-One option would be to try to more carefully limit the requirements of
-each function. There are many functions which would have to be checked.
-However as has been shown in the std::copy case, this may be difficult.
-A simpler, more global option would be to somewhere insert text similar to:
-</p>
-
-<p>
-If the execution of any function would change either any values passed
-by reference or any value in any range passed to a function in a way not
-defined in the definition of that function, the result is undefined.
-</p>
-
-<p>
-Such code would have to at least cover chapters 23 and 25 (the sections
-I read through carefully). I can see no harm on applying it to much of
-the rest of the standard.
-</p>
-
-<p>
-Some existing parts of the standard could be improved to fit with this,
-for example the requires for 25.2.1 (Copy) could be adjusted to:
-</p>
-
-<p>
-Requires: For each non-negative integer n &lt; (last - first), assigning to
-*(result + n) must not alter any value in the range [first + n, last).
-</p>
-
-<p>
-However, this may add excessive complication.
-</p>
-
-<p>
-One other benefit of clearly introducing this text is that it would
-allow a number of small optimisations, such as caching values passed
-by const reference.
-</p>
-
-<p>
-Matt Austern adds that this issue also exists for the <tt>insert</tt> and
-<tt>erase</tt> members of the ordered and unordered associative containers.
-</p>
-
-<p><i>[
-Berlin: Lots of controversey over how this should be solved. Lots of confusion
-as to whether we're talking about self referencing iterators or references.
-Needs a good survey as to the cases where this matters, for which
-implementations, and how expensive it is to fix each case.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD.
-</p>
-<ul>
-<li><tt>vector::insert(iter, value)</tt> is required to work because the standard
-doesn't give permission for it not to work.</li>
-<li><tt>list::remove(value)</tt> is required to work because the standard
-doesn't give permission for it not to work.</li>
-<li><tt>vector::insert(iter, iter, iter)</tt> is not required to work because
-23.1.3 [sequence.reqmts], p4 says so.</li>
-<li><tt>copy</tt> has to work, except where 25.2.1 [alg.copy] says
-it doesn't have to work. While a language lawyer can tear this wording apart,
-it is felt that the wording is not prone to accidental interpretation.</li>
-<li>The current working draft provide exceptions for the unordered associative
-containers similar to the containers requirements which exempt the member
-template insert functions from self referencing.</li>
-</ul>
-
-
-
-
-
-<hr>
-<h3><a name="528"></a>528. <tt>const_iterator</tt> <tt>iterator</tt> issue when they are the same type</h3>
-<p><b>Section:</b> 23.4 [unord], TR1 6.3.4 [tr.unord.unord] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-10-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord">active issues</a> in [unord].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord">issues</a> in [unord].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-while implementing the resolution of issue 6.19 I'm noticing the
-following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and
-unordered_multiset:
-</p>
-
-<blockquote><p>
- "The iterator and const_iterator types are both const types. It is
-unspecified whether they are the same type"
-</p></blockquote>
-
-<p>
-Now, according to the resolution of 6.19, we have overloads of insert
-with hint and erase (single and range) both for iterator and
-const_iterator, which, AFAICS, can be meaningful at the same time *only*
-if iterator and const_iterator *are* in fact different types.
-</p>
-<p>
-Then, iterator and const_iterator are *required* to be different types?
-Or that is an unintended consequence? Maybe the overloads for plain
-iterators should be added only to unordered_map and unordered_multimap?
-Or, of course, I'm missing something?
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to 6.3.4.3p2 (and 6.3.4.5p2):
-</p>
-<p>
-2 ... The iterator and const_iterator types are both <del>const</del>
-<ins>constant</ins> iterator types.
-It is unspecified whether they are the same type.
-</p>
-
-<p>
-Add a new subsection to 17.4.4 [lib.conforming]:
-</p>
-
-<blockquote>
-<p>
-An implementation shall not supply an overloaded function
- signature specified in any library clause if such a signature
- would be inherently ambiguous during overload resolution
- due to two library types referring to the same type.
-</p>
-<p>
- [Note: For example, this occurs when a container's iterator
- and const_iterator types are the same. -- end note]
-</p>
-</blockquote>
-
-<p><i>[
-Post-Berlin: Beman supplied wording.
-]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-Toronto: The first issue has been fixed by N2350 (the insert and erase members
-are collapsed into one signature). Alisdair to open a separate issue on the
-chapter 17 wording.
-
-
-
-
-
-<hr>
-<h3><a name="529"></a>529. The standard encourages redundant and confusing preconditions</h3>
-<p><b>Section:</b> 17.4.3.10 [res.on.required] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-10-25</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-17.4.3.8/1 says:
-</p>
-
-<blockquote><p>
-Violation of the preconditions specified in a function's
-Required behavior: paragraph results in undefined behavior unless the
-function's Throws: paragraph specifies throwing an exception when the
-precondition is violated.
-</p></blockquote>
-
-<p>
-This implies that a precondition violation can lead to defined
-behavior. That conflicts with the only reasonable definition of
-precondition: that a violation leads to undefined behavior. Any other
-definition muddies the waters when it comes to analyzing program
-correctness, because precondition violations may be routinely done in
-correct code (e.g. you can use std::vector::at with the full
-expectation that you'll get an exception when your index is out of
-range, catch the exception, and continue). Not only is it a bad
-example to set, but it encourages needless complication and redundancy
-in the standard. For example:
-</p>
-
-<blockquote><pre> 21 Strings library
- 21.3.3 basic_string capacity
-
- void resize(size_type n, charT c);
-
- 5 Requires: n &lt;= max_size()
- 6 Throws: length_error if n &gt; max_size().
- 7 Effects: Alters the length of the string designated by *this as follows:
-</pre></blockquote>
-
-<p>
-The Requires clause is entirely redundant and can be dropped. We
-could make that simplifying change (and many others like it) even
-without changing 17.4.3.8/1; the wording there just seems to encourage
-the redundant and error-prone Requires: clause.
-</p>
-
-<p><i>[
-Batavia: Alan and Pete to work.
-]</i></p>
-
-
-<p><i>[
-Bellevue: NAD Editorial, this group likes
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>,
-Pete agrees, accepting it is Pete's business.
-General agreement that precondition violations are synonymous with UB.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-1. Change 17.4.3.8/1 to read:
-</p>
-
-<blockquote><p>
-Violation of the preconditions specified in a function's
-<i>Required behavior:</i> paragraph results in undefined behavior
-<del>unless the function's <i>Throws:</i> paragraph specifies throwing
-an exception when the precondition is violated</del>.
-</p></blockquote>
-
-<p>
-2. Go through and remove redundant Requires: clauses. Specifics to be
- provided by Dave A.
-</p>
-
-<p><i>[
-Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution.
-]</i></p>
-
-
-<p><i>[
-Alan provided the survey
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2121.html">N2121</a>.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="532"></a>532. Tuple comparison</h3>
-<p><b>Section:</b> 20.4.1.6 [tuple.rel], TR1 6.1.3.5 [tr.tuple.rel] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> David Abrahams <b>Date:</b> 2005-11-29</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a></p>
-<p><b>Discussion:</b></p>
-<p>
-Where possible, tuple comparison operators &lt;,&lt;=,=&gt;, and &gt; ought to be
-defined in terms of std::less rather than operator&lt;, in order to
-support comparison of tuples of pointers.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-change 6.1.3.5/5 from:
-</p>
-
-<blockquote><p>
- Returns: The result of a lexicographical comparison between t and
- u. The result is defined as: (bool)(get&lt;0&gt;(t) &lt; get&lt;0&gt;(u)) ||
- (!(bool)(get&lt;0&gt;(u) &lt; get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for
- some tuple r is a tuple containing all but the first element of
- r. For any two zero-length tuples e and f, e &lt; f returns false.
-</p></blockquote>
-
-<p>
-to:
-</p>
-
-<blockquote>
-<p>
- Returns: The result of a lexicographical comparison between t and
- u. For any two zero-length tuples e and f, e &lt; f returns false.
- Otherwise, the result is defined as: cmp( get&lt;0&gt;(t), get&lt;0&gt;(u)) ||
- (!cmp(get&lt;0&gt;(u), get&lt;0&gt;(t)) &amp;&amp; ttail &lt; utail), where rtail for some
- tuple r is a tuple containing all but the first element of r, and
- cmp(x,y) is an unspecified function template defined as follows.
-</p>
-<p>
- Where T is the type of x and U is the type of y:
-</p>
-
-<p>
- if T and U are pointer types and T is convertible to U, returns
- less&lt;U&gt;()(x,y)
-</p>
-
-<p>
- otherwise, if T and U are pointer types, returns less&lt;T&gt;()(x,y)
-</p>
-
-<p>
- otherwise, returns (bool)(x &lt; y)
-</p>
-</blockquote>
-
-<p><i>[
-Berlin: This issue is much bigger than just tuple (pair, containers,
-algorithms). Dietmar will survey and work up proposed wording.
-]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD. This will be fixed with the next revision of concepts.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="536"></a>536. Container iterator constructor and explicit convertibility</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Joaqun M Lpez Muoz <b>Date:</b> 2005-12-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a></p>
-<p><b>Discussion:</b></p>
-<p>
-The iterator constructor X(i,j) for containers as defined in 23.1.1 and
-23.2.2 does only require that i and j be input iterators but
-nothing is said about their associated value_type. There are three
-sensible
-options:
-</p>
-<ol>
-<li>iterator's value_type is exactly X::value_type (modulo cv).</li>
-<li>iterator's value_type is *implicitly* convertible to X::value_type.</li>
-<li>iterator's value_type is *explicitly* convertible to X::value_type.</li>
-</ol>
-<p>
-The issue has practical implications, and stdlib vendors have
-taken divergent approaches to it: Dinkumware follows 2,
-libstdc++ follows 3.
-</p>
-<p>
-The same problem applies to the definition of insert(p,i,j) for
-sequences and insert(i,j) for associative contianers, as well as
-assign.
-</p>
-
-<p><i>[
-The following added by Howard and the example code was originally written by
-Dietmar.
-]</i></p>
-
-<p>
-Valid code below?
-</p>
-
-<blockquote><pre>#include &lt;vector&gt;
-#include &lt;iterator&gt;
-#include &lt;iostream&gt;
-
-struct foo
-{
- explicit foo(int) {}
-};
-
-int main()
-{
- std::vector&lt;int&gt; v_int;
- std::vector&lt;foo&gt; v_foo1(v_int.begin(), v_int.end());
- std::vector&lt;foo&gt; v_foo2((std::istream_iterator&lt;int&gt;(std::cin)),
- std::istream_iterator&lt;int&gt;());
-}
-</pre></blockquote>
-<p><i>[
-Berlin: Some support, not universal, for respecting the explicit qualifier.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="544"></a>544. minor NULL problems in C.2</h3>
-<p><b>Section:</b> C.2 [diff.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-11-25</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-According to C.2.2.3, p1, "the macro NULL, defined in any of &lt;clocale&gt;,
-&lt;cstddef&gt;, &lt;cstdio&gt;, &lt;cstdlib&gt;, &lt;cstring&gt;, &lt;ctime&gt;,
-or &lt;cwchar&gt;." This is consistent with the C standard.
-</p>
-<p>
-However, Table 95 in C.2 fails to mention &lt;clocale&gt; and &lt;cstdlib&gt;.
-</p>
-<p>
-In addition, C.2, p2 claims that "The C++ Standard library provides
-54 standard macros from the C library, as shown in Table 95." While
-table 95 does have 54 entries, since a couple of them (including the
-NULL macro) are listed more than once, the actual number of macros
-defined by the C++ Standard Library may not be 54.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-I propose we add &lt;clocale&gt; and &lt;cstdlib&gt; to Table 96 and remove the
-number of macros from C.2, p2 and reword the sentence as follows:
-</p>
-<blockquote><p>
-The C++ Standard library <del>provides 54 standard macros from</del>
-<ins>defines a number macros corresponding to those defined by</ins> the C
-<ins>Standard</ins> library, as shown in Table 96.
-</p></blockquote>
-
-<p><i>[
-Portland: Resolution is considered editorial. It will be incorporated into the WD.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="547"></a>547. division should be floating-point, not integer</h3>
-<p><b>Section:</b> 26.4 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Paragraph 10 describes how a variate generator uses numbers produced by an
-engine to pass to a generator. The sentence that concerns me is: "Otherwise, if
-the value for engine_value_type::result_type is true and the value for
-Distribution::input_type is false [i.e. if the engine produces integers and the
-engine wants floating-point values], then the numbers in s_eng are divided by
-engine().max() - engine().min() + 1 to obtain the numbers in s_e." Since the
-engine is producing integers, both the numerator and the denominator are
-integers and we'll be doing integer division, which I don't think is what we
-want. Shouldn't we be performing a conversion to a floating-point type first?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD as the affected section is now gone and so the issue is moot.
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="548"></a>548. May random_device block?</h3>
-<p><b>Section:</b> 26.4.6 [rand.device], TR1 5.1.6 [tr.rand.device] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Class random_device "produces non-deterministic random numbers", using some
-external source of entropy. In most real-world systems, the amount of available
-entropy is limited. Suppose that entropy has been exhausted. What is an
-implementation permitted to do? In particular, is it permitted to block
-indefinitely until more random bits are available, or is the implementation
-required to detect failure immediately? This is not an academic question. On
-Linux a straightforward implementation would read from /dev/random, and "When
-the entropy pool is empty, reads to /dev/random will block until additional
-environmental noise is gathered." Programmers need to know whether random_device
-is permitted to (or possibly even required to?) behave the same way.
-</p>
-
-<p><i>[
-Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin
-may block?
-]</i></p>
-
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a> (NAD).
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="549"></a>549. Undefined variable in binomial_distribution</h3>
-<p><b>Section:</b> 26.4.8 [rand.dist], TR1 5.1.7.5 [tr.rand.dist.bin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist">issues</a> in [rand.dist].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Paragraph 1 says that "A binomial distributon random distribution produces
-integer values i&gt;0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and
-p are the parameters of the distribution. OK, that tells us what t, p, and i
-are. What's n?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1.
-</p>
-
-<p><i>[
-Portland: Subsumed by N2111.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="553"></a>553. very minor editorial change intptr_t / uintptr_t</h3>
-<p><b>Section:</b> 18.3.1 [cstdint.syn], TR1 8.22.1 [tr.c99.cstdint.syn] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-01-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint.syn">issues</a> in [cstdint.syn].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In the synopsis, some types are identified as optional: int8_t, int16_t,
-and so on, consistently with C99, indeed.
-</p>
-<p>
-On the other hand, intptr_t and uintptr_t, are not marked as such and
-probably should, consistently with C99, 7.18.1.4.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 18.3.1 [cstdint.syn]:
-</p>
-
-<blockquote><pre>...
-typedef <i>signed integer type</i> intptr_t; <ins><i>// optional</i></ins>
-...
-typedef <i>unsigned integer type</i> uintptr_t; <ins><i>// optional</i></ins>
-...
-</pre></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-Recommend NAD and fix as editorial with the proposed resolution.
-
-
-
-
-
-<hr>
-<h3><a name="554"></a>554. Problem with lwg DR 184 numeric_limits&lt;bool&gt;</h3>
-<p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I believe we have a bug in the resolution of:
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">lwg 184</a>
-(WP status).
-</p>
-
-<p>
-The resolution spells out each member of <tt>numeric_limits&lt;bool&gt;</tt>.
-The part I'm having a little trouble with is:
-</p>
-<blockquote><pre>static const bool traps = false;
-</pre></blockquote>
-
-<p>
-Should this not be implementation defined? Given:
-</p>
-
-<blockquote><pre>int main()
-{
- bool b1 = true;
- bool b2 = false;
- bool b3 = b1/b2;
-}
-</pre></blockquote>
-
-<p>
-If this causes a trap, shouldn't <tt>numeric_limits&lt;bool&gt;::traps</tt> be
-<tt>true</tt>?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 18.2.1.5p3:
-</p>
-
-<blockquote><p>
--3- The specialization for <tt>bool</tt> shall be provided as follows: </p>
-<blockquote><pre>namespace std {
- template &lt;&gt; class numeric_limits&lt;bool&gt; {
- ...
- static const bool traps = <del>false</del> <ins><i>implementation-defined</i></ins>;
- ...
- };
-}
-</pre></blockquote>
-</blockquote>
-
-<p><i>[
-Redmond: NAD because traps refers to values, not operations. There is no bool
-value that will trap.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="555"></a>555. TR1, 8.21/1: typo</h3>
-<p><b>Section:</b> TR1 8.21 [tr.c99.boolh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-02</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-This one, if nobody noticed it yet, seems really editorial:
-s/cstbool/cstdbool/
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 8.21p1:
-</p>
-<blockquote><p>
--1- The header behaves as if it defines the additional macro defined in
-<tt>&lt;cst<ins>d</ins>bool&gt;</tt> by including the header <tt>&lt;cstdbool&gt;</tt>.
-</p></blockquote>
-
-<p><i>[
-Redmond: Editorial.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="557"></a>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3>
-<p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
-long long we end up, essentially, with the same arguments and different
-return types (lldiv_t and imaxdiv_t, respectively). Similar issue with
-abs(_Longlong) and abs(intmax_t), of course.
-</p>
-<p>
-Comparing sections 8.25 and 8.11, I see an important difference,
-however: 8.25.3 and 8.25.4 carefully describe div and abs for _Longlong
-types (rightfully, because not moved over directly from C99), whereas
-there is no equivalent in 8.11: the abs and div overloads for intmax_t
-types appear only in the synopsis and are not described anywhere, in
-particular no mention in 8.11.2 (at variance with 8.25.2).
-</p>
-<p>
-I'm wondering whether we really, really, want div and abs for intmax_t...
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-<p><i>[
-Portland: no consensus.
-]</i></p>
-
-
-<p><b>Rationale:</b></p>
-<p><i>[
-Batavia, Bill: The <tt>&lt;cstdint&gt;</tt> synopsis in TR1 8.11.1 [tr.c99.cinttypes.syn] contains:
-]</i></p>
-
-<blockquote><pre>intmax_t imaxabs(intmax_t i);
-intmax_t abs(intmax_t i);
-
-imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
-imaxdiv_t div(intmax_t numer, intmax_t denom);
-</pre></blockquote>
-
-<p><i>[
-and in TR1 8.11.2 [tr.c99.cinttypes.def]:
-]</i></p>
-
-
-<blockquote><p>
-The header defines all functions, types, and macros the same as C99
-subclause 7.8.
-</p></blockquote>
-
-<p><i>[
-This is as much definition as we give for most other C99 functions,
-so nothing need change. We might, however, choose to add the footnote:
-]</i></p>
-
-
-<blockquote><p>
-[<i>Note:</i> These overloads for <tt>abs</tt> and <tt>div</tt> may well be equivalent to
-those that take <tt>long long</tt> arguments. If so, the implementation is
-responsible for avoiding conflicting declarations. -- <i>end note</i>]
-</p></blockquote>
-
-<p><i>[
-Bellevue: NAD Editorial. Pete must add a footnote, as described below.
-]</i></p>
-
-
-<blockquote>
-<p><i>[
-Looks like a real problem. Dietmar suggests div() return a template
-type. Matt: looks like imaxdiv_t is loosly defined. Can it be a typedef
-for lldiv_t when _Longlong == intmax_t? PJP seems to agree. We would
-need a non-normative note declaring that the types lldiv_t and imaxdiv_t
-may not be unique if intmax_t==_longlong.
-]</i></p>
-
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="558"></a>558. lib.input.iterators Defect</h3>
-<p><b>Section:</b> 24.1.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> David Abrahams <b>Date:</b> 2006-02-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<blockquote>
-<p>
- 24.1.1 Input iterators [lib.input.iterators]
-</p>
-<p>
- 1 A class or a built-in type X satisfies the requirements of an
- input iterator for the value type T if the following expressions are
- valid, where U is the type of any specified member of type T, as
- shown in Table 73.
-</p>
-</blockquote>
-<p>
-There is no capital U used in table 73. There is a lowercase u, but
-that is clearly not meant to denote a member of type T. Also, there's
-no description in 24.1.1 of what lowercase a means. IMO the above
-should have been...Hah, a and b are already covered in 24.1/11, so maybe it
-should have just been:
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 24.1.1p1:
-</p>
-<blockquote><p>
--1- A class or a built-in type <tt>X</tt> satisfies the requirements of an
-input iterator for the value type <tt>T</tt> if the following expressions
-are valid<del>, where <tt>U</tt> is the type of any specified member of type
-<tt>T</tt>,</del> as shown in Table 73.
-</p></blockquote>
-
-<p><i>[
-Portland: Editorial.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="560"></a>560. User-defined allocators without default constructor</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Sergey P. Derevyago <b>Date:</b> 2006-02-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<h4>1. The essence of the problem.</h4>
-<p>
-User-defined allocators without default constructor are not explicitly
-supported by the standard but they can be supported just like std::vector
-supports elements without default constructor.
-</p>
-<p>
-As a result, there exist implementations that work well with such allocators
-and implementations that don't.
-</p>
-
-<h4>2. The cause of the problem.</h4>
-<p>
-1) The standard doesn't explicitly state this intent but it should. In
-particular, 20.1.5p5 explicitly state the intent w.r.t. the allocator
-instances that compare non-equal. So it can similarly state the intent w.r.t.
-the user-defined allocators without default constructor.
-</p>
-<p>
-2) Some container operations are obviously underspecified. In particular,
-21.3.7.1p2 tells:
-</p>
-<blockquote><pre>template&lt;class charT, class traits, class Allocator&gt;
- basic_string&lt;charT,traits,Allocator&gt; operator+(
- const charT* lhs,
- const basic_string&lt;charT,traits,Allocator&gt;&amp; rhs
- );
-</pre>
-<p>
-Returns: <tt>basic_string&lt;charT,traits,Allocator&gt;(lhs) + rhs</tt>.
-</p>
-</blockquote>
-<p>
-That leads to the basic_string&lt;charT,traits,Allocator&gt;(lhs, Allocator()) call.
-Obviously, the right requirement is:
-</p>
-<blockquote><p>
-Returns: <tt>basic_string&lt;charT,traits,Allocator&gt;(lhs, rhs.get_allocator()) + rhs</tt>.
-</p></blockquote>
-<p>
-It seems like a lot of DRs can be submitted on this "Absent call to
-get_allocator()" topic.
-</p>
-
-<h4>3. Proposed actions.</h4>
-<p>
-1) Explicitly state the intent to allow for user-defined allocators without
-default constructor in 20.1.5 Allocator requirements.
-</p>
-<p>
-2) Correct all the places, where a correct allocator object is available
-through the get_allocator() call but default Allocator() gets passed instead.
-</p>
-<h4>4. Code sample.</h4>
-<p>
-Let's suppose that the following memory pool is available:
-</p>
-<blockquote><pre>class mem_pool {
- // ...
- void* allocate(size_t size);
- void deallocate(void* ptr, size_t size);
-};
-</pre></blockquote>
-<p>
-So the following allocator can be implemented via this pool:
-</p>
-<blockquote><pre>class stl_allocator {
- mem_pool&amp; pool;
-
- public:
- explicit stl_allocator(mem_pool&amp; mp) : pool(mp) {}
- stl_allocator(const stl_allocator&amp; sa) : pool(sa.pool) {}
- template &lt;class U&gt;
- stl_allocator(const stl_allocator&lt;U&gt;&amp; sa) : pool(sa.get_pool()) {}
- ~stl_allocator() {}
-
- pointer allocate(size_type n, std::allocator&lt;void&gt;::const_pointer = 0)
- {
- return (n!=0) ? static_cast&lt;pointer&gt;(pool.allocate(n*sizeof(T))) : 0;
- }
-
- void deallocate(pointer p, size_type n)
- {
- if (n!=0) pool.deallocate(p, n*sizeof(T));
- }
-
- // ...
-};
-</pre></blockquote>
-<p>
-Then the following code works well on some implementations and doesn't work on
-another:
-</p>
-<blockquote><pre>typedef basic_string&lt;char, char_traits&lt;char&gt;, stl_allocator&lt;char&gt; &gt;
- tl_string;
-mem_pool mp;
-tl_string s1("abc", stl_allocator&lt;int&gt;(mp));
-printf("(%s)\n", ("def"+s1).c_str());
-</pre></blockquote>
-<p>
-In particular, on some implementations the code can't be compiled without
-default stl_allocator() constructor.
-</p>
-<p>
-The obvious way to solve the compile-time problems is to intentionally define
-a NULL pointer dereferencing default constructor
-</p>
-<blockquote><pre>stl_allocator() : pool(*static_cast&lt;mem_pool*&gt;(0)) {}
-</pre></blockquote>
-<p>
-in a hope that it will not be called. The problem is that it really gets
-called by operator+(const char*, const string&amp;) under the current 21.3.7.1p2
-wording.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD. <tt>operator+()</tt> with <tt>string</tt> already requires the desired
-semantics of copying the allocator from one of the strings (<i>lhs</i> when there is a choice).
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="569"></a>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</h3>
-<p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-03-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a></p>
-<p><b>Discussion:</b></p>
-<p>
-Section: 27.4.4.3 [lib.iostate.flags]
-</p>
-<p>
-Paragraph 4 says:
-</p>
-<blockquote>
-<blockquote><pre>void clear(iostate <i>state</i> = goodbit);
-</pre></blockquote>
-<p>
-<i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt>
-otherwise <tt>rdstate()==<i>state</i>|ios_base::badbit</tt>.
-</p>
-</blockquote>
-
-<p>
-The postcondition "rdstate()==state|ios_base::badbit" is parsed as
-"(rdstate()==state)|ios_base::badbit", which is probably what the
-committee meant.
-</p>
-
-
-
-
-<p><b>Rationale:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="570"></a>570. Request adding additional explicit specializations of char_traits</h3>
-<p><b>Section:</b> 21.1 [char.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Jack Reeves <b>Date:</b> 2006-04-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits">issues</a> in [char.traits].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Currently, the Standard Library specifies only a declaration for template class
-char_traits&lt;&gt; and requires the implementation provide two explicit
-specializations: char_traits&lt;char&gt; and char_traits&lt;wchar_t&gt;. I feel the Standard
-should require explicit specializations for all built-in character types, i.e.
-char, wchar_t, unsigned char, and signed char.
-</p>
-<p>
-I have put together a paper
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>)
-that describes this in more detail and
-includes all the necessary wording.
-</p>
-<p><i>[
-Portland: Jack will rewrite
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1985.htm">N1985</a>
-to propose a primary template that will work with other integral types.
-]</i></p>
-
-<p><i>[
-Toronto: issue has grown with addition of <tt>char16_t</tt> and <tt>char32_t</tt>.
-]</i></p>
-
-
-<p><i>[
-post Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-We suggest that Jack be asked about the status of his paper, and if it
-is not forthcoming, the work-item be assigned to someone else. If no one
-steps forward to do the paper before the next meeting, we propose to
-make this NAD without further discussion. We leave this Open for now,
-but our recommendation is NAD.
-</p>
-<p>
-Note: the issue statement should be updated, as the Toronto comment has
-already been resolved. E.g., char_traits specializations for char16_t
-and char32_t are now in the working paper.
-</p>
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-Nobody has submitted the requested paper, so we move to NAD, as suggested by the decision at the last meeting.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="571"></a>571. Update C90 references to C99?</h3>
-<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-04-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC
-9899:1990, Programming languages - C. Should that be changed to ISO/IEC
-9899:1999?
-</p>
-<p>
-What impact does this have on the library?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 1.2/1 [intro.refs] of the WP, change:
-</p>
-<blockquote>
-<ul>
-<li>ISO/IEC 9899:<del>1990</del><ins>1999 + TC1 + TC2</ins>, <i>Programming languages - C</i></li>
-</ul>
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-Recommend NAD, fixed editorially.
-
-
-
-
-
-<hr>
-<h3><a name="572"></a>572. Oops, we gave 507 WP status</h3>
-<p><b>Section:</b> 26.4 [rand], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-04-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot:
-variate_generator has been eliminated. Then in full committee we voted to give
-this issue WP status (mistakenly).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Strike the proposed resolution of issue 507.
-</p>
-<p><i>[
-post-Portland: Walter and Howard recommend NAD. The proposed resolution of 507 no longer
-exists in the current WD.
-]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-NAD. Will be moot once
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2135.pdf">N2135</a>
-is adopted.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="579"></a>579. erase(iterator) for unordered containers should not return an iterator</h3>
-<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Joaqun M Lpez Muoz <b>Date:</b> 2006-06-13</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-See
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
-for full discussion.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Option 1:
-</p>
-
-<p>
-The problem can be eliminated by omitting the requirement that <tt>a.erase(q)</tt> return an
-iterator. This is, however, in contrast with the equivalent requirements for other
-standard containers.
-</p>
-
-<p>
-Option 2:
-</p>
-
-<p>
-<tt>a.erase(q)</tt> can be made to compute the next iterator only when explicitly requested:
-the technique consists in returning a proxy object implicitly convertible to <tt>iterator</tt>, so
-that
-</p>
-
-<blockquote><pre>iterator q1=a.erase(q);
-</pre></blockquote>
-
-<p>
-works as expected, while
-</p>
-
-<blockquote><pre>a.erase(q);
-</pre></blockquote>
-
-<p>
-does not ever invoke the conversion-to-iterator operator, thus avoiding the associated
-computation. To allow this technique, some sections of TR1 along the line "return value
-is an iterator..." should be changed to "return value is an unspecified object implicitly
-convertible to an iterator..." Although this trick is expected to work transparently, it can
-have some collateral effects when the expression <tt>a.erase(q)</tt> is used inside generic
-code.
-</p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf">N2023</a>
-was discussed in Portland and the consensus was that there appears to be
-no need for either change proposed in the paper. The consensus opinion
-was that since the iterator could serve as its own proxy, there appears
-to be no need for the change. In general, "converts to" is undesirable
-because it interferes with template matching.
-</p>
-
-<p>
-Post Toronto: There does not at this time appear to be consensus with the Portland consensus.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-The Bellevue review of this issue reached consensus with the Portland
-consensus, in contravention of the Toronto non-consensus. Common
-implementations have the iterator readily available, and most common
-uses depend on the iterator being returned.
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="583"></a>583. div() for unsigned integral types</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There is no div() function for unsigned integer types.
-</p>
-<p>
-There are several possible resolutions. The simplest one is noted below. Other
-possibilities include a templated solution.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to 26.7 [lib.c.math] paragraph 8:
-</p>
-
-<blockquote><pre>struct udiv_t div(unsigned, unsigned);
-struct uldiv_t div(unsigned long, unsigned long);
-struct ulldiv_t div(unsigned long long, unsigned long long);
-</pre></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-Toronto: C99 does not have these unsigned versions because
-the signed version exist just to define the implementation-defined behavior
-of signed integer division. Unsigned integer division has no implementation-defined
-behavior and thus does not need this treatment.
-
-
-
-
-
-<hr>
-<h3><a name="584"></a>584. missing int pow(int,int) functionality</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-06-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There is no pow() function for any integral type.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add something like:
-</p>
-
-<blockquote><pre>template&lt; typename T&gt;
-T power( T x, int n );
-// requires: n &gt;=0
-</pre></blockquote>
-
-
-<p><b>Rationale:</b></p>
-Toronto: We already have double pow(integral, integral) from 26.7 [c.math] p11.
-
-
-
-
-
-<hr>
-<h3><a name="587"></a>587. iststream ctor missing description</h3>
-<p><b>Section:</b> D.7.2.1 [depr.istrstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The <code>iststream(char*, streamsize)</code> ctor is in the class
-synopsis in D.7.2 but its signature is missing in the description
-below (in D.7.2.1).
-
- </p>
-
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-This seems like a simple editorial issue and the missing signature can
-be added to the one for <code>const char*</code> in paragraph 2.
-
- </p>
-
-<p><i>[
-post Oxford: Noted that it is already fixed in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="590"></a>590. Type traits implementation latitude should be removed for C++0x</h3>
-<p><b>Section:</b> 20.5 [meta], TR1 4.9 [tr.meta.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2006-08-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta">issues</a> in [meta].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-20.4.9 [lib.meta.req], Implementation requirements, provides latitude for type
-traits implementers that is not needed in C++0x. It includes the wording:
-</p>
-
-<blockquote><p>
-[<i>Note:</i> the latitude granted to implementers in this clause is temporary,
-and is expected to be removed in future revisions of this document. -- <i>end note</i>]
-</p></blockquote>
-
-<p>
-Note:
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2157.html">N2157: Minor Modifications to the type traits Wording</a>
-also has the intent of removing this wording from the WP.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove 20.4.9 [lib.meta.req] in its entirety from the WP.
-</p>
-
-<p><i>[
-post-Oxford: Recommend NAD Editorial. This resolution is now in the
-current working draft.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="591"></a>591. Misleading "built-in</h3>
-<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> whyglinux <b>Date:</b> 2006-08-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-18.2.1.2 numeric_limits members [lib.numeric.limits.members]
-Paragraph 7:
-</p>
-<blockquote><p>
-"For built-in integer types, the number of non-sign bits in the
-representation."
-</p></blockquote>
-
-<p>
-26.1 Numeric type requirements [lib.numeric.requirements]
-Footnote:
-</p>
-
-<blockquote><p>
-"In other words, value types. These include built-in arithmetic types,
-pointers, the library class complex, and instantiations of valarray for
-value types."
-</p></blockquote>
-
-<p>
-Integer types (which are bool, char, wchar_t, and the signed and
-unsigned integer types) and arithmetic types (which are integer and
-floating types) are all built-in types and thus there are no
-non-built-in (that is, user-defined) integer or arithmetic types. Since
-the redundant "built-in" in the above 2 sentences can mislead that
-there may be built-in or user-defined integer and arithmetic types
-(which is not correct), the "built-in" should be removed.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-18.2.1.2 numeric_limits members [lib.numeric.limits.members]
-Paragraph 7:
-</p>
-<blockquote><p>
-"For <del>built-in</del> integer types, the number of non-sign bits in the
-representation."
-</p></blockquote>
-
-<p>
-26.1 Numeric type requirements [lib.numeric.requirements]
-Footnote:
-</p>
-
-<blockquote><p>
-"In other words, value types. These include <del>built-in</del> arithmetic types,
-pointers, the library class complex, and instantiations of valarray for
-value types."
-</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD / Editorial. The proposed resolution is accepted as editorial.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="592"></a>592. Incorrect treatment of rdbuf()-&gt;close() return type</h3>
-<p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Christopher Kohlhoff <b>Date:</b> 2006-08-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I just spotted a minor problem in 27.8.1.7
-[lib.ifstream.members] para 4 and also 27.8.1.13
-[lib.fstream.members] para 4. In both places it says:
-</p>
-<blockquote>
-<pre>void close();
-</pre>
-<p>
-Effects: Calls rdbuf()-&gt;close() and, if that function returns false, ...
-</p>
-</blockquote>
-<p>
-However, basic_filebuf::close() (27.8.1.2) returns a pointer to the
-filebuf on success, null on failure, so I think it is meant to
-say "if that function returns a null pointer". Oddly, it is
-correct for basic_ofstream.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 27.8.1.9 [ifstream.members], p5:
-</p>
-
-<blockquote><p>
-<i>Effects:</i> Calls <tt>rdbuf()-&gt;close()</tt> and, if that function
-<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
-calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
-(27.4.4.3)).
-</p></blockquote>
-
-<p>
-Change 27.8.1.17 [fstream.members], p5:
-</p>
-
-<blockquote><p>
-<i>Effects:</i> Calls <tt>rdbuf()-&gt;close()</tt> and, if that function
-<ins>fails (</ins>returns <del><tt>false</tt></del> <ins>a null pointer)</ins>,
-calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>
-(27.4.4.3)).
-</p></blockquote>
-
-
-
-<p><i>[
-Kona (2007): Proposed Disposition: NAD, Editorial
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="594"></a>594. Disadvantages of defining Swappable in terms of CopyConstructible and Assignable</h3>
-<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> Niels Dekker <b>Date:</b> 2006-11-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It seems undesirable to define the Swappable requirement in terms of
-CopyConstructible and Assignable requirements. And likewise, once the
-MoveConstructible and MoveAssignable requirements (N1860) have made it
-into the Working Draft, it seems undesirable to define the Swappable
-requirement in terms of those requirements. Instead, it appears
-preferable to have the Swappable requirement defined exclusively in
-terms of the existence of an appropriate swap function.
-</p>
-<p>
-Section 20.1.4 [lib.swappable] of the current Working Draft (N2009)
-says:
-</p>
-<blockquote><p>
-The Swappable requirement is met by satisfying one or more of the
-following conditions:</p>
-<ul>
-<li>
-T is Swappable if T satisfies the CopyConstructible requirements
-(20.1.3) and the Assignable requirements (23.1);
-</li>
-<li>
-T is Swappable if a namespace scope function named swap exists in the
-same namespace as the definition of T, such that the expression
-swap(t,u) is valid and has the semantics described in Table 33.
-</li>
-</ul>
-</blockquote>
-I can think of three disadvantages of this definition:
-<ol>
-<li>
-If a client's type T satisfies the first condition (T is both
-CopyConstructible and Assignable), the client cannot stop T from
-satisfying the Swappable requirement without stopping T from
-satisfying the first condition.
-<p>
-A client might want to stop T from satisfying the Swappable
-requirement, because swapping by means of copy construction and
-assignment might throw an exception, and she might find a throwing
-swap unacceptable for her type. On the other hand, she might not feel
-the need to fully implement her own swap function for this type. In
-this case she would want to be able to simply prevent algorithms that
-would swap objects of type T from being used, e.g., by declaring a
-swap function for T, and leaving this function purposely undefined.
-This would trigger a link error, if an attempt would be made to use
-such an algorithm for this type. For most standard library
-implementations, this practice would indeed have the effect of
-stopping T from satisfying the Swappable requirement.
-</p>
-</li>
-<li>
-A client's type T that does not satisfy the first condition can not be
-made Swappable by providing a specialization of std::swap for T.
-<p>
-While I'm aware about the fact that people have mixed feelings about
-providing a specialization of std::swap, it is well-defined to do so.
-It sounds rather counter-intuitive to say that T is not Swappable, if
-it has a valid and semantically correct specialization of std::swap.
-Also in practice, providing such a specialization will have the same
-effect as satisfying the Swappable requirement.
-</p>
-</li>
-<li>
-For a client's type T that satisfies both conditions of the Swappable
-requirement, it is not specified which of the two conditions prevails.
-After reading section 20.1.4 [lib.swappable], one might wonder whether
-objects of T will be swapped by doing copy construction and
-assignments, or by calling the swap function of T.
-<p>
-I'm aware that the intention of the Draft is to prefer calling the
-swap function of T over doing copy construction and assignments. Still
-in my opinion, it would be better to make this clear in the wording of
-the definition of Swappable.
-</p>
-</li>
-</ol>
-<p>
-I would like to have the Swappable requirement defined in such a way
-that the following code fragment will correctly swap two objects of a
-type T, if and only if T is Swappable:
-</p>
-<pre> using std::swap;
- swap(t, u); // t and u are of type T.
-</pre>
-<p>
-This is also the way Scott Meyers recommends calling a swap function,
-in Effective C++, Third Edition, item 25.
-</p>
-<p>
-Most aspects of this issue have been dealt with in a discussion on
-comp.std.c++ about the Swappable requirement, from 13 September to 4
-October 2006, including valuable input by David Abrahams, Pete Becker,
-Greg Herlihy, Howard Hinnant and others.
-</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change section 20.1.4 [lib.swappable] as follows:
-</p>
-<blockquote><p>
-The Swappable requirement is met by satisfying
-<del>one or more of the following conditions:</del>
-<ins>the following condition:</ins></p>
-<ul>
-
-<li>
-<del>T is Swappable if T satisfies the CopyConstructible requirements
-(20.1.3) and the Assignable requirements (23.1);</del>
-</li>
-<li>
-<del>
-T is Swappable if a namespace scope function named swap exists in the
-same namespace as the definition of T, such that the expression
-swap(t,u) is valid and has the semantics described in Table 33.
-</del>
-T is Swappable if an unqualified function call swap(t,u) is valid
-within the namespace std, and has the semantics described in Table 33.
-</li>
-</ul>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD. Concepts, specifically
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2082.pdf">N2082</a>
-and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2084.pdf">N2084</a>,
-will essentially rewrite this section and provide the desired semantics.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="615"></a>615. Inconsistencies in Section 21.4</h3>
-<p><b>Section:</b> 21.5 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In the current draft N2134, 21.4/1 says
-</p>
-<p>
-"Tables 59,228) 60, 61, 62,and 63 229) 230) describe headers &lt;cctype&gt;,
-&lt;cwctype&gt;, &lt;cstring&gt;, &lt;cwchar&gt;, and &lt;cstdlib&gt; (character conversions),
-respectively."
-</p>
-<p>
-Here footnote 229 applies to table 62, not table 63.
-</p>
-<p>
-Also, footnote 230 lists the new functions in table 63, "atoll, strtoll,
-strtoull, strtof, and strtold added by TR1". However, strtof is not present
-in table 63.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Recommend NAD, editorial. Send to Pete.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="625"></a>625. mixed up <i>Effects</i> and <i>Returns</i> clauses</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-Many member functions of <code>basic_string</code> are overloaded,
-with some of the overloads taking a <code>string</code> argument,
-others <code>value_type*</code>, others <code>size_type</code>, and
-others still <code>iterators</code>. Often, the requirements on one of
-the overloads are expressed in the form of <i>Effects</i>,
-<i>Throws</i>, and in the Working Paper
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
-also <i>Remark</i> clauses, while those on the rest of the overloads
-via a reference to this overload and using a <i>Returns</i> clause.
-
- </p><p>
- </p>
-
-The difference between the two forms of specification is that per
-17.3.1.3 [structure.specifications], p3, an <i>Effects</i> clause specifies
-<i>"actions performed by the functions,"</i> i.e., its observable
-effects, while a <i>Returns</i> clause is <i>"a description of the
-return value(s) of a function"</i> that does not impose any
-requirements on the function's observable effects.
-
- <p>
- </p>
-
-Since only <i>Notes</i> are explicitly defined to be informative and
-all other paragraphs are explicitly defined to be normative, like
-<i>Effects</i> and <i>Returns</i>, the new <i>Remark</i> clauses also
-impose normative requirements.
-
- <p>
- </p>
-
-So by this strict reading of the standard there are some member
-functions of <code>basic_string</code> that are required to throw an
-exception under some conditions or use specific traits members while
-many other otherwise equivalent overloads, while obliged to return the
-same values, aren't required to follow the exact same requirements
-with regards to the observable effects.
-
- <p>
- </p>
-
-Here's an example of this problem that was precipitated by the change
-from informative Notes to normative <i>Remark</i>s (presumably made to
-address <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>):
-
- <p>
- </p>
-
-In the Working Paper, <code>find(string, size_type)</code> contains a
-<i>Remark</i> clause (which is just a <i>Note</i> in the current
-standard) requiring it to use <code>traits::eq()</code>.
-
- <p>
- </p>
-
-<code>find(const charT *s, size_type pos)</code> is specified to
-return <code>find(string(s), pos)</code> by a <i>Returns</i> clause
-and so it is not required to use <code>traits::eq()</code>. However,
-the Working Paper has replaced the original informative <i>Note</i>
-about the function using <code>traits::length()</code> with a
-normative requirement in the form of a <i>Remark</i>. Calling
-<code>traits::length()</code> may be suboptimal, for example when the
-argument is a very long array whose initial substring doesn't appear
-anywhere in <code>*this</code>.
-
- <p>
- </p>
-
-Here's another similar example, one that existed even prior to the
-introduction of <i>Remark</i>s:
-
- <p>
- </p>
-
-<code> insert(size_type pos, string, size_type, size_type)</code> is
-required to throw <code>out_of_range</code> if <code>pos &gt;
-size()</code>.
-
- <p>
- </p>
-
-<code>insert(size_type pos, string str)</code> is specified to return
-<code>insert(pos, str, 0, npos)</code> by a <i>Returns</i> clause and
-so its effects when <code>pos &gt; size()</code> are strictly speaking
-unspecified.
-
-
- <p>
-
-I believe a careful review of the current <i>Effects</i> and
-<i>Returns</i> clauses is needed in order to identify all such
-problematic cases. In addition, a review of the Working Paper should
-be done to make sure that the newly introduced normative <i>Remark</i>
-clauses do not impose any undesirable normative requirements in place
-of the original informative <i>Notes</i>.
-
- </p>
-<p><i>[
-Batavia: Alan and Pete to work.
-]</i></p>
-
-
-<p><i>[
-Bellevue: Marked as NAD Editorial.
-]</i></p>
-
-
-<p><i>[
-Post-Sophia Antipolis: Martin indicates there is still work to be done on this issue.
-Reopened.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="626"></a>626. new <i>Remark</i> clauses not documented</h3>
-<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The <i>Remark</i> clauses newly introduced into the Working Paper
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
-are not mentioned in 17.3.1.3 [structure.specifications] where we list the
-meaning of <i>Effects</i>, <i>Requires</i>, and other clauses (with
-the exception of <i>Notes</i> which are documented as informative in
-17.3.1.1 [structure.summary], p2, and which they replace in many cases).
-
- </p>
- <p>
-
-Propose add a bullet for <i>Remarks</i> along with a brief description.
-
- </p>
-<p><i>[
-Batavia: Alan and Pete to work.
-]</i></p>
-
-
-<p><i>[
-Bellevue: Already resolved in current working paper.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="627"></a>627. Low memory and exceptions</h3>
-<p><b>Section:</b> 18.5.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-01-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I recognize the need for nothrow guarantees in the exception reporting
-mechanism, but I strongly believe that implementors also need an escape hatch
-when memory gets really low. (Like, there's not enough heap to construct and
-copy exception objects, or not enough stack to process the throw.) I'd like to
-think we can put this escape hatch in 18.5.1.1 [new.delete.single],
-<tt>operator new</tt>, but I'm not sure how to do it. We need more than a
-footnote, but the wording has to be a bit vague. The idea is that if
-<tt>new</tt> can't allocate something sufficiently small, it has the right to
-<tt>abort</tt>/call <tt>terminate</tt>/call <tt>unexpected</tt>.
-</p>
-
-<p><i>[
-Bellevue: NAD. 1.4p2 specifies a program must behave correctly "within
-its resource limits", so no further escape hatch is necessary.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="633"></a>633. Return clause mentions undefined "type()"</h3>
-<p><b>Section:</b> 20.6.15.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-02-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-20.6.15.2.5 [func.wrap.func.targ], p4 says:
-</p>
-<blockquote><p>
-<i>Returns:</i> If <tt>type() == typeid(T)</tt>, a pointer to the stored
-function target; otherwise a null pointer.
-</p></blockquote>
-
-<ol>
-<li>
-There exists neither a type, a typedef <tt>type</tt>, nor member
-function <tt>type()</tt> in class template function nor in the global or
-<tt>std</tt> namespace.
-</li>
-<li>
-Assuming that <tt>type</tt> should have been <tt>target_type()</tt>,
-this description would lead to false results, if <tt>T = <i>cv</i>
-void</tt> due to returns clause 20.6.15.2.5 [func.wrap.func.targ], p1.
-</li>
-</ol>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.6.15.2.5 [func.wrap.func.targ], p4:
-</p>
-
-<blockquote><p>
-<i>Returns:</i> If <tt><del>type()</del> <ins>target_type()</ins> == typeid(T) <ins>&amp;&amp; typeid(T) !=
-typeid(void)</ins></tt>, a pointer to the stored function target;
-otherwise a null pointer.
-</p></blockquote>
-
-<p><i>[
-Pete: Agreed. It's editorial, so I'll fix it.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="636"></a>636. 26.5.2.3 valarray::operator[]</h3>
-<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The signature of the const operator[] has been changed to return a const
-reference.
-</p>
-<p>
-The description in paragraph 1 still says that the operator returns by
-value.
-</p>
-<p><i>[
-Pete recommends editorial fix.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="637"></a>637. [c.math]/10 inconsistent return values</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-02-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-26.7 [c.math], paragraph 10 has long lists of added signatures for float and long double
-functions. All the signatures have float/long double return values, which is
-inconsistent with some of the double functions they are supposed to
-overload.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.7 [c.math], paragraph 10,
-</p>
-
-<blockquote><pre><del>float</del> <ins>int</ins> ilogb(float);
-<del>float</del> <ins>long</ins> lrint(float);
-<del>float</del> <ins>long</ins> lround(float);
-<del>float</del> <ins>long long</ins> llrint(float);
-<del>float</del> <ins>long long</ins> llround(float);
-
-<del>long double</del> <ins>int</ins> ilogb(long double);
-<del>long double</del> <ins>long</ins> lrint(long double);
-<del>long double</del> <ins>long</ins> lround(long double);
-<del>long double</del> <ins>long long</ins> llrint(long double);
-<del>long double</del> <ins>long long</ins> llround(long double);
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="639"></a>639. Still problems with exceptions during streambuf IO</h3>
-<p><b>Section:</b> 27.6.1.2.3 [istream::extractors], 27.6.2.6.3 [ostream.inserters] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-02-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There already exist two active DR's for the wording of 27.6.1.2.3 [istream::extractors]/13
-from 14882:2003(E), namely <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#413">413</a>.
-</p>
-
-<p>
-Even with these proposed corrections, already maintained in N2134,
-I have the feeling, that the current wording does still not properly
-handle the "exceptional" situation. The combination of para 14
-</p>
-
-<blockquote><p>
-"[..] Characters are extracted and inserted until
-any of the following occurs:
-</p>
-<p>
-[..]
-</p>
-<p>
-- an exception occurs (in which case the exception is caught)."
-</p></blockquote>
-
-<p>
-and 15
-</p>
-
-<blockquote><p>
-"If the function inserts no characters, it calls setstate(failbit),
-which
-may throw ios_base::failure (27.4.4.3). If it inserted no characters
-because it caught an exception thrown while extracting characters
-from *this and failbit is on in exceptions() (27.4.4.3), then the
-caught
-exception is rethrown."
-</p></blockquote>
-
-<p>
-both in N2134 seems to imply that any exception, which occurs
-*after* at least one character has been inserted is caught and lost
-for
-ever. It seems that even if failbit is on in exceptions() rethrow is
-not
-allowed due to the wording "If it inserted no characters because it
-caught an exception thrown while extracting".
-</p>
-
-<p>
-Is this behaviour by design?
-</p>
-
-<p>
-I would like to add that its output counterpart in 27.6.2.6.3 [ostream.inserters]/7-9
-(also
-N2134) does not demonstrate such an exception-loss-behaviour.
-On the other side, I wonder concerning several subtle differences
-compared to input::
-</p>
-<p>
-1) Paragraph 8 says at its end:
-</p>
-
-<blockquote><p>
-"- an exception occurs while getting a character from sb."
-</p></blockquote>
-
-<p>
-Note that there is nothing mentioned which would imply that such
-an exception will be caught compared to 27.6.1.2.3 [istream::extractors]/14.
-</p>
-
-<p>
-2) Paragraph 9 says:
-</p>
-
-<blockquote><p>
-"If the function inserts no characters, it calls setstate(failbit)
-(which
-may throw ios_base::failure (27.4.4.3)). If an exception was thrown
-while extracting a character, the function sets failbit in error
-state,
-and if failbit is on in exceptions() the caught exception is
-rethrown."
-</p></blockquote>
-
-<p>
-The sentence starting with "If an exception was thrown" seems to
-imply that such an exception *should* be caught before.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-(a) In 27.6.1.2.3 [istream::extractors]/15 (N2134) change the sentence
-</p>
-
-<blockquote><p>
-If the function inserts no characters, it calls
-<tt>setstate(failbit)</tt>, which may throw <tt>ios_base::failure</tt>
-(27.4.4.3). If <del>it inserted no characters because it caught an
-exception thrown while extracting characters from <tt>*this</tt></del>
-<ins>an exception was thrown while extracting a character from
-<tt>*this</tt>, the function sets <tt>failbit</tt> in error state,</ins>
-and <tt>failbit</tt> is on in <tt>exceptions()</tt> (27.4.4.3), then the
-caught exception is rethrown.
-</p></blockquote>
-
-<p>
-(b) In 27.6.2.6.3 [ostream.inserters]/8 (N2134) change the sentence:
-</p>
-
-<blockquote>
-<p>
-Gets characters from <tt>sb</tt> and inserts them in <tt>*this</tt>.
-Characters are read from <tt>sb</tt> and inserted until any of the
-following occurs:
-</p>
-<ul>
-<li>end-of-file occurs on the input sequence;</li>
-<li>inserting in the output sequence fails (in which case the character to be inserted is not extracted);</li>
-<li>an exception occurs while getting a character from <tt>sb</tt> <ins>(in which
-case the exception is caught)</ins>.</li>
-</ul>
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-This extractor is described as a formatted input function so the
-exception behavior is already specified. There is additional behavior
-described in this section that applies to the case in which failbit is
-set. This doesn't contradict the usual exception behavior for formatted
-input functions because that applies to the case in which badbit is set.
-
-
-
-
-
-<hr>
-<h3><a name="641"></a>641. Editorial fix for 27.6.4 (N2134)</h3>
-<p><b>Section:</b> 27.6.4 [ext.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-02-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ext.manip">active issues</a> in [ext.manip].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ext.manip">issues</a> in [ext.manip].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The function <tt>f</tt> in para 4 (27.6.4 [ext.manip]) references an unknown <tt>strm</tt>
-in the following line:
-</p>
-
-<blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, strm, err, mon);
-</pre></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 27.6.4 [ext.manip], p4:
-</p>
-
-<blockquote><pre>mg.get(Iter(str.rdbuf()), Iter(), intl, str<del>m</del>, err, mon);
-</pre></blockquote>
-
-<p><i>[
-Oxford: Editorial.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="642"></a>642. Invalidated fstream footnotes in N2134</h3>
-<p><b>Section:</b> 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-02-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The standard wording of N2134 has extended the 14882:2003(E)
-wording for the ifstream/ofstream/fstream open function to fix
-a long standing problem, see <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409">409</a>.
-</p>
-
-<p>
-Now it's properly written as
-</p>
-
-<blockquote><p>
-"If that function does not return a null pointer calls clear(),
-otherwise
-calls setstate(failbit)[..]"
-</p></blockquote>
-
-<p>
-instead of the previous
-</p>
-
-<blockquote><p>
-"If that function returns a null pointer, calls setstate(failbit)[..]
-</p></blockquote>
-
-<p>
-While the old footnotes saying
-</p>
-
-<blockquote><p>
-"A successful open does not change the error state."
-</p></blockquote>
-
-<p>
-where correct and important, they are invalid now for ifstream and
-ofstream (because clear *does* indeed modify the error state) and
-should be removed (Interestingly fstream itself never had these,
-although
-they where needed for that time).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.8.1.9 [ifstream.members], remove footnote:
-</p>
-
-<blockquote><p>
-<del><sup>334)</sup> A successful open does not change the error state.</del>
-</p></blockquote>
-
-<p>
-In 27.8.1.13 [ofstream.members], remove footnote:
-</p>
-
-<blockquote><p>
-<del><sup>335)</sup> A successful open does not change the error state.</del>
-</p></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="645"></a>645. Missing members in match_results</h3>
-<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-02-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-According to the description given in 28.10 [re.results]/2 the class template
-match_results "shall satisfy the requirements of a Sequence, [..],
-except that only operations defined for const-qualified Sequences
-are supported".
-Comparing the provided operations from 28.10 [re.results]/3 with the
-sequence/container tables 80 and 81 one recognizes the following
-missing operations:
-</p>
-
-<p>
-1) The members
-</p>
-
-<blockquote><pre>const_iterator rbegin() const;
-const_iterator rend() const;
-</pre></blockquote>
-
-<p>
-should exists because 23.1/10 demands these for containers
-(all sequences are containers) which support bidirectional
-iterators. Aren't these supported by match_result? This is not
-explicitely expressed, but it's somewhat implied by two arguments:
-</p>
-<p>
-(a) Several typedefs delegate to
-<tt>iterator_traits&lt;BidirectionalIterator&gt;</tt>.
-</p>
-<p>
-(b) The existence of <tt>const_reference operator[](size_type n) const</tt>
-implies even random-access iteration.
-I also suggest, that <tt>match_result</tt> should explicitly mention,
-which minimum iterator category is supported and if this does
-not include random-access the existence of <tt>operator[]</tt> is
-somewhat questionable.
-</p>
-<p>
-2) The new "convenience" members
-</p>
-<blockquote><pre>const_iterator cbegin() const;
-const_iterator cend() const;
-const_iterator crbegin() const;
-const_iterator crend() const;
-</pre></blockquote>
-<p>
-should be added according to tables 80/81.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following members to the <tt>match_results</tt> synopsis after <tt>end()</tt> in 28.10 [re.results]
-para 3:
-</p>
-
-<blockquote><pre>const_iterator cbegin() const;
-const_iterator cend() const;
-</pre></blockquote>
-
-<p>
-In section 28.10.3 [re.results.acc] change:
-</p>
-
-<blockquote>
-<pre>const_iterator begin() const;
-<ins>const_iterator cbegin() const;</ins>
-</pre>
-<blockquote>
-<p>
--7- <i>Returns:</i> A starting iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
-</p>
-</blockquote>
-
-<pre>const_iterator end() const;
-<ins>const_iterator cend() const;</ins>
-</pre>
-<blockquote>
-<p>
--8- <i>Returns:</i> A terminating iterator that enumerates over all the sub-expressions stored in <tt>*this</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-<p><i>[
-Kona (2007): Voted to adopt proposed wording in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>
-except removing the entry in the table container requirements. Moved to Review.
-]</i></p>
-
-
-<p><i>[
-Bellevue: Proposed wording now in the WP.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="647"></a>647. Inconsistent regex_search params</h3>
-<p><b>Section:</b> 28.11.3 [re.alg.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-02-26</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-28.11.3 [re.alg.search]/5 declares
-</p>
-
-<blockquote><pre>template &lt;class iterator, class charT, class traits&gt;
-bool regex_search(iterator first, iterator last,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-</pre></blockquote>
-
-<p>
-where it's not explained, which iterator category
-the parameter iterator belongs to. This is inconsistent
-to the preceding declaration in the synopsis section
-28.4 [re.syn], which says:
-</p>
-
-<blockquote><pre>template &lt;class BidirectionalIterator, class charT, class traits&gt;
-bool regex_search(BidirectionalIterator first, BidirectionalIterator last,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-</pre></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 28.11.3 [re.alg.search]/5 replace all three occurences of param "iterator" with
-"BidirectionalIterator"
-</p>
-
-<blockquote><pre>template &lt;class <del>iterator</del> <ins>BidirectionalIterator</ins>, class charT, class traits&gt;
- bool regex_search(<del>iterator</del> <ins>BidirectionalIterator</ins> first, <del>iterator</del> <ins>BidirectionalIterator</ins> last,
- const basic_regex&lt;charT, traits&gt;&amp; e,
- regex_constants::match_flag_type flags =
- regex_constants::match_default);
-</pre>
-<p>
--6- <i>Effects:</i> Behaves "as if" by constructing an object what of
-type <tt>match_results&lt;<del>iterator</del>
-<ins>BidirectionalIterator</ins>&gt;</tt> and then returning the result
-of <tt>regex_search(first, last, what, e, flags)</tt>.
-</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-Applied to working paper while issue was still in New status.
-
-
-
-
-
-<hr>
-<h3><a name="648"></a>648. regex_iterator c'tor needs clarification/editorial fix</h3>
-<p><b>Section:</b> 28.12.1.1 [re.regiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-03-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 28.12.1.1 [re.regiter.cnstr]/2 the effects paragraph starts with:
-</p>
-
-<blockquote>
-<p>
-<i>Effects:</i> Initializes begin and end to point to the beginning and the
-end of the target sequence, sets pregex to &amp;re, sets flags to f,[..]
-</p></blockquote>
-
-<p>
-There are two issues with this description:
-</p>
-
-<ol>
-<li>
-The meaning of very first part of this quote is unclear, because
-there is no target sequence provided, instead there are given two
-parameters a and b, both of type BidirectionalIterator. The mentioned
-part does not explain what a and b represent.
-</li>
-<li>
-There does not exist any parameter f, but instead a parameter
-m in the constructor declaration, so this is actually an editorial
-fix.
-</li>
-</ol>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 28.12.1.1 [re.regiter.cnstr]/2 change the above quoted part by
-</p>
-
-<blockquote><p>
-<i>Effects:</i> Initializes <tt>begin</tt> and <tt>end</tt> to point to
-the beginning and the end of the target sequence <ins>designated by the
-iterator range <tt>[a, b)</tt></ins>, sets <tt>pregex</tt> to
-<tt>&amp;re</tt>, sets <tt>flags</tt> to <tt><del>f</del>
-<ins>m</ins></tt>, then calls <tt>regex_search(begin, end, match,
-*pregex, flags)</tt>. If this call returns <tt>false</tt> the
-constructor sets <tt>*this</tt> to the end-of-sequence iterator.
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="649"></a>649. Several typos in regex_token_iterator constructors</h3>
-<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-03-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 28.12.2.1 [re.tokiter.cnstr]/1+2 both the constructor declaration
-and the following text shows some obvious typos:
-</p>
-<p>
-1) The third constructor form is written as
-</p>
-<blockquote><pre>template &lt;std::size_t N&gt;
- regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
- const regex_type&amp; re,
- const int (&amp;submatches)[R],
- regex_constants::match_flag_type m =
- regex_constants::match_default);
-</pre></blockquote>
-
-<p>
-where the dimensions of submatches are specified by an
-unknown value R, which should be N.
-</p>
-<p>
-2) Paragraph 2 of the same section says in its last sentence:
-</p>
-
-<blockquote><p>
-The third constructor initializes the member <tt>subs</tt> to hold a
-copy of the sequence of integer values pointed to by the iterator range
-<tt>[&amp;submatches, &amp;submatches + R)</tt>.
-</p></blockquote>
-
-<p>
-where again R must be replaced by N.
-</p>
-
-<p>
-3) Paragraph 3 of the same section says in its first sentence:
-</p>
-
-<blockquote><p>
-Each constructor then sets <tt>N</tt> to <tt>0</tt>, and
-<tt>position</tt> to <tt>position_iterator(a, b, re, f)</tt>.
-</p></blockquote>
-
-<p>
-where a non-existing parameter "f" is mentioned, which must be
-replaced
-by the parameter "m".
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 28.12.2.1 [re.tokiter.cnstr]/1:
-</p>
-<blockquote><pre>template &lt;std::size_t N&gt;
- regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b,
- const regex_type&amp; re,
- const int (&amp;submatches)[<del>R</del> <ins>N</ins>],
- regex_constants::match_flag_type m =
- regex_constants::match_default);
-</pre></blockquote>
-
-<p>
-Change 28.12.2.1 [re.tokiter.cnstr]/2:
-</p>
-
-<blockquote><p>
-<i>Effects:</i> The first constructor initializes the member
-<tt>subs</tt> to hold the single value <tt>submatch</tt>. The second
-constructor initializes the member <tt>subs</tt> to hold a copy of the
-argument <tt>submatches</tt>. The third constructor initializes the
-member <tt>subs</tt> to hold a copy of the sequence of integer values
-pointed to by the iterator range <tt>[&amp;submatches, &amp;submatches +
-<del>R</del> <ins>N</ins>)</tt>.
-</p></blockquote>
-
-<p>
-Change 28.12.2.1 [re.tokiter.cnstr]/3:
-</p>
-
-<blockquote><p>
-Each constructor then sets <tt>N</tt> to <tt>0</tt>, and
-<tt>position</tt> to <tt>position_iterator(a, b, re, <del>f</del>
-<ins>m</ins>)</tt>. If <tt>position</tt> is not an end-of-sequence
-iterator the constructor sets <tt>result</tt> to the address of the
-current match. Otherwise if any of the values stored in <tt>subs</tt> is
-equal to <tt>-1</tt> the constructor sets <tt>*this</tt> to a suffix
-iterator that points to the range <tt>[a, b)</tt>, otherwise the
-constructor sets <tt>*this</tt> to an end-of-sequence iterator.
-</p></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="653"></a>653. Library reserved names</h3>
-<p><b>Section:</b> 1.2 [intro.refs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-03-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#intro.refs">issues</a> in [intro.refs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-</p>
-<blockquote>
-<p>
-1.2 [intro.refs] Normative references
-</p>
-
-<p>
-The following standards contain provisions which, through reference in
-this text, constitute provisions of this Interna- tional Standard. At
-the time of publication, the editions indicated were valid. All
-standards are subject to revision, and parties to agreements based on
-this International Standard are encouraged to investigate the
-possibility of applying the most recent editions of the standards
-indicated below. Members of IEC and ISO maintain registers of currently
-valid International Standards.
-</p>
-
-<ul>
-<li>Ecma International, ECMAScript Language Specification, Standard
-Ecma-262, third edition, 1999.</li>
-<li>ISO/IEC 2382 (all parts), Information technology - Vocabulary</li>
-<li>ISO/IEC 9899:1990, Programming languages - C</li>
-<li>ISO/IEC 9899/Amd.1:1995, Programming languages - C, AMENDMENT 1: C
-Integrity</li>
-<li>ISO/IEC 9899:1999, Programming languages - C</li>
-<li>ISO/IEC 9899:1999/Cor.1:2001 Programming languages - C</li>
-<li>ISO/IEC 9899:1999/Cor.2:2004 Programming languages - C</li>
-<li>ISO/IEC 9945:2003, Information Technology-Portable Operating System
-Interface (POSIX)</li>
-<li>ISO/IEC 10646-1:1993 Information technology - Universal Multiple-Octet
-Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual
-Plane</li>
-</ul>
-</blockquote>
-
-<p>
-I'm not sure how many of those reserve naming patterns that might affect
-us, but I am equally sure I don't own a copy of any of these to check!
-</p>
-<p>
-The point is to list the reserved naming patterns, rather than the
-individual names themselves - although we may want to list C keywords
-that are valid identifiers in C++ but likely to cause trouble in shared
-headers (e.g. restrict)
-</p>
-
-<p><i>[
-Kona (2007): Recommend NAD. No one has identified a specific defect, just the possibility of one.
-]</i></p>
-
-
-<p><i>[
-Post-Kona: Alisdair request Open. A good example of the problem was a
-discussion of the system error proposal, where it was pointed out an all-caps
-identifier starting with a capital E conflicted with reserved macro names for
-both Posix and C. I had absolutely no idea of this rule, and suspect I was
-not the only one in the room.<br>
-<br>
-Resolution will require someone with access to all the listed documents to
-research their respective name reservation rules, or people with access to
-specific documents add their rules to this issue until the list is complete.
-]</i></p>
-
-
-<p><i>[
-Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording.
-Suggest a formal paper rather than a defect report is the correct way to proceed.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="656"></a>656. Typo in subtract_with_carry_engine declaration</h3>
-<p><b>Section:</b> 26.4.2 [rand.synopsis] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-03-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.synopsis">issues</a> in [rand.synopsis].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-26.4.2 [rand.synopsis] the header <tt>&lt;random&gt;</tt> synopsis
-contains an unreasonable closing curly brace inside the
-<tt>subtract_with_carry_engine</tt> declaration.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the current declaration in 26.4.2 [rand.synopsis]
-</p>
-
-<blockquote><pre>template &lt;class UIntType, size_t w<del>}</del>, size_t s, size_t r&gt;
-class subtract_with_carry_engine;
-</pre></blockquote>
-
-
-<p><i>[
-Pete: Recommends editorial.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="657"></a>657. unclear requirement about header inclusion</h3>
-<p><b>Section:</b> 17.4.2.1 [using.headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Gennaro Prota <b>Date:</b> 2007-03-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-17.4.2.1 [using.headers] states:
-</p>
-
-<blockquote><p>
-A translation unit shall include a header only outside of any
-external declaration or definition, [...]
-</p></blockquote>
-
-<p>
-I see three problems with this requirement:
-</p>
-
-<ol type="a">
-<li><p>The C++ standard doesn't define what an "external declaration" or
-an "external definition" are (incidentally the C99 standard does, and
-has a sentence very similar to the above regarding header inclusion).
-</p><p>
-I think the intent is that the #include directive shall lexically
-appear outside *any* declaration; instead, when the issue was pointed
-out on comp.std.c++ at least one poster interpreted "external
-declaration" as "declaration of an identifier with external linkage".
-If this were the correct interpretation, then the two inclusions below
-would be legal:
-</p>
-<blockquote><pre> // at global scope
- static void f()
- {
-# include &lt;cstddef&gt;
- }
-
- static void g()
- {
-# include &lt;stddef.h&gt;
- }
-</pre></blockquote>
-<p>
-(note that while the first example is unlikely to compile correctly,
-the second one may well do)
-</p></li>
-
-<li><p>as the sentence stands, violations will require a diagnostic; is
-this the intent? It was pointed out on comp.std.c++ (by several
-posters) that at least one way to ensure a diagnostic exists:
-</p>
-<blockquote><p>
- [If there is an actual file for each header,] one simple way
- to implement this would be to insert a reserved identifier
- such as __begin_header at the start of each standard header.
- This reserved identifier would be ignored for all other
- purposes, except that, at the appropriate point in phase 7, if
- it is found inside an external definition, a diagnostic is
- generated. There's many other similar ways to achieve the same
- effect.
- </p>
-<p> --James Kuyper, on comp.std.c++
-</p></blockquote></li>
-
-<li><p>is the term "header" meant to be limited to standard headers?
-Clause 17 is all about the library, but still the general question is
-interesting and affects one of the points in the explicit namespaces
-proposal (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1691.html">n1691</a>):
-</p>
-<blockquote><p>
- Those seeking to conveniently enable argument-dependent
- lookups for all operators within an explicit namespace
- could easily create a header file that does so:
-</p><pre> namespace mymath::
- {
- #include "using_ops.hpp"
- }
-</pre></blockquote>
-</li>
-</ol>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-<p><b>Rationale:</b></p>
-We believe that the existing language does not cause any real confusion
-and any new formulation of the rules that we could come up with are
-unlikely to be better than what's already in the standard.
-
-
-
-
-
-<hr>
-<h3><a name="658"></a>658. Two unspecified function comparators in [function.objects]</h3>
-<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-03-19</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The header <tt>&lt;functional&gt;</tt> synopsis in 20.6 [function.objects]
-contains the following two free comparison operator templates
-for the <tt>function</tt> class template
-</p>
-
-<blockquote><pre>template&lt;class Function1, class Function2&gt;
-void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
-template&lt;class Function1, class Function2&gt;
-void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
-</pre></blockquote>
-
-<p>
-which are nowhere described. I assume that they are relicts before the
-corresponding two private and undefined member templates in the function
-template (see 20.6.15.2 [func.wrap.func] and X [func.wrap.func.undef]) have been introduced. The original free
-function templates should be removed, because using an undefined entity
-would lead to an ODR violation of the user.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove the above mentioned two function templates from
-the header <tt>&lt;functional&gt;</tt> synopsis (20.6 [function.objects])
-</p>
-
-<blockquote><pre><del>template&lt;class Function1, class Function2&gt;
-void operator==(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);
-template&lt;class Function1, class Function2&gt;
-void operator!=(const function&lt;Function1&gt;&amp;, const function&lt;Function2&gt;&amp;);</del>
-</pre></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-Fixed by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2292.html">N2292</a>
-Standard Library Applications for Deleted Functions.
-
-
-
-
-
-<hr>
-<h3><a name="662"></a>662. Inconsistent handling of incorrectly-placed thousands separators</h3>
-<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Cosmin Truta <b>Date:</b> 2007-04-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-From Section 22.2.2.1.2 [facet.num.get.virtuals], paragraphs 11 and 12, it is implied
-that the value read from a stream must be stored
-even if the placement of thousands separators does not conform to the
-<code>grouping()</code> specification from the <code>numpunct</code> facet.
-Since incorrectly-placed thousands separators are flagged as an extraction
-failure (by the means of <code>failbit</code>), we believe it is better not
-to store the value. A consistent strategy, in which any kind of extraction
-failure leaves the input item intact, is conceptually cleaner, is able to avoid
-corner-case traps, and is also more understandable from the programmer's point
-of view.
-</p>
-<p>
-Here is a quote from <i>"The C++ Programming Language (Special Edition)"</i>
-by B.&nbsp;Stroustrup (Section&nbsp;D.4.2.3, pg.&nbsp;897):
-</p>
-<blockquote><p>
-<i>"If a value of the desired type could not be read, failbit is set in r.
-[...] An input operator will use r to determine how to set the state of its
-stream. If no error was encountered, the value read is assigned through v;
-otherwise, v is left unchanged."</i>
-</p></blockquote>
-<p>
-This statement implies that <code>rdstate()</code> alone is sufficient to
-determine whether an extracted value is to be assigned to the input item
-<i>val</i> passed to <code>do_get</code>. However, this is in disagreement
-with the current C++ Standard. The above-mentioned assumption is true in all
-cases, except when there are mismatches in digit grouping. In the latter case,
-the parsed value is assigned to <i>val</i>, and, at the same time, <i>err</i>
-is assigned to <code>ios_base::failbit</code> (essentially "lying" about the
-success of the operation). Is this intentional? The current behavior raises
-both consistency and usability concerns.
-</p>
-<p>
-Although digit grouping is outside the scope of <code>scanf</code> (on which
-the virtual methods of <code>num_get</code> are based), handling of grouping
-should be consistent with the overall behavior of scanf. The specification of
-<code>scanf</code> makes a distinction between input failures and matching
-failures, and yet both kinds of failures have no effect on the input items
-passed to <code>scanf</code>. A mismatch in digit grouping logically falls in
-the category of matching failures, and it would be more consistent, and less
-surprising to the user, to leave the input item intact whenever a failure is
-being signaled.
-</p>
-<p>
-The extraction of <code>bool</code> is another example outside the scope of
-<code>scanf</code>, and yet consistent, even in the event of a successful
-extraction of a <code>long</code> but a failed conversion from
-<code>long</code> to <code>bool</code>.
-</p>
-<p>
-Inconsistency is further aggravated by the fact that, when failbit is set,
-subsequent extraction operations are no-ops until <code>failbit</code> is
-explicitly cleared. Assuming that there is no explicit handling of
-<code>rdstate()</code> (as in <code>cin&gt;&gt;i&gt;&gt;j</code>) it is
-counter-intuitive to be able to extract an integer with mismatched digit
-grouping, but to be unable to extract another, properly-formatted integer
-that immediately follows.
-</p>
-<p>
-Moreover, setting <code>failbit</code>, and selectively assigning a value to
-the input item, raises usability problems. Either the strategy of
-<code>scanf</code> (when there is no extracted value in case of failure), or
-the strategy of the <code>strtol</code> family (when there is always an
-extracted value, and there are well-defined defaults in case of a failure) are
-easy to understand and easy to use. On the other hand, if <code>failbit</code>
-alone cannot consistently make a difference between a failed extraction, and a
-successful but not-quite-correct extraction whose output happens to be the same
-as the previous value, the programmer must resort to implementation tricks.
-Consider the following example:
-</p>
-<pre> int i = old_i;
- cin &gt;&gt; i;
- if (cin.fail())
- // can the value of i be trusted?
- // what does it mean if i == old_i?
- // ...
-</pre>
-<p>
-Last but not least, the current behvaior is not only confusing to the casual
-reader, but it has also been confusing to some book authors. Besides
-Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by
-Langer and Kreft) are describing the same mistaken assumption. Although books
-are not to be used instead of the standard reference, the readers of these
-books, as well as the people who are generally familiar to <code>scanf</code>,
-are even more likely to misinterpret the standard, and expect the input items
-to remain intact when a failure occurs.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 22.2.2.1.2 [facet.num.get.virtuals]:
-</p>
-
-<blockquote>
-<p>
-<b>Stage 3:</b> The result of stage 2 processing can be one of
-</p>
-<ul>
-<li>A sequence of <code>chars</code> has been accumulated in stage 2 that is converted (according to the rules of <code>scanf</code>) to a value of the type of <code><i>val</i></code>. <del>This value is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</del></li>
-
-<li>The sequence of <code>chars</code> accumulated in stage 2 would have caused <code>scanf</code> to report an input failure. <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>.</li>
-</ul>
-<p>
-<ins>In the first case,</ins> <del>D</del><ins>d</ins>igit grouping is checked. That is, the positions of discarded separators is examined for consistency with <code>use_facet&lt;numpunct&lt;charT&gt; &gt;(<i>loc</i>).grouping()</code>. If they are not consistent then <code>ios_base::failbit</code> is assigned to <code><i>err</i></code>. <ins>Otherwise, the value that was converted in stage 2 is stored in <code><i>val</i></code> and <code>ios_base::goodbit</code> is stored in <code><i>err</i></code>.</ins>
-</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-post-Toronto: Changed from New to NAD at the request of the author. The preferred solution of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2327.pdf">N2327</a>
-makes this resolution obsolete.
-
-
-
-
-
-<hr>
-<h3><a name="663"></a>663. Complexity Requirements</h3>
-<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-17.3.1.3 [structure.specifications] para 5 says
-</p>
-
-<blockquote><p>
--5- Complexity requirements specified in the library&nbsp;
-clauses are upper bounds, and implementations that provide better
-complexity guarantees satisfy the requirements.
-</p></blockquote>
-
-<p>
-The following
-objection has been raised:
-</p>
-
-<blockquote><p>
-The library clauses suggest general
-guidelines regarding complexity, but we have been unable to discover
-any absolute hard-and-fast formulae for these requirements.&nbsp; Unless
-or until the Library group standardizes specific hard-and-fast
-formulae, we regard all the complexity requirements as subject to a&nbsp;
-"fudge factor" without any intrinsic upper bound.
-</p></blockquote>
-
-<p>
-[Plum ref&nbsp;
-_23213Y31 etc]
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-<p><b>Rationale:</b></p>
-Kona (2007): No specific instances of underspecification have been
-identified, and big-O notation always involves constant factors.
-
-
-
-
-
-<hr>
-<h3><a name="683"></a>683. regex_token_iterator summary error</h3>
-<p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-28.12.2 [re.tokiter], p3 says:
-</p>
-<blockquote>
-<p>
-After it is constructed, the iterator finds and stores a value
-<tt>match_results&lt;BidirectionalIterator&gt;</tt> position and sets the
-internal count <tt>N</tt> to zero.
-</p>
-</blockquote>
-
-<p>
-Should read:
-</p>
-
-<blockquote>
-<p>
-After it is constructed, the iterator finds and stores a value
-<tt><del>match_results</del><ins>regex_iterator</ins>&lt;BidirectionalIterator<ins>, charT, traits</ins>&gt;</tt>
-position and sets the internal count <tt>N</tt> to zero.
-</p>
-</blockquote>
-
-<p><i>[
-John adds:
-]</i></p>
-
-
-<blockquote><p>
-Yep, looks like a typo/administrative fix to me.
-</p></blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="684"></a>684. Unclear which members of match_results should be used in comparison</h3>
-<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.results">issues</a> in [re.results].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 28.4 [re.syn] of N2284, two template functions
-are declared here:
-</p>
-<blockquote><pre>// 28.10, class template match_results:
- &lt;<i>snip</i>&gt;
-// match_results comparisons
- template &lt;class BidirectionalIterator, class Allocator&gt;
- bool operator== (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
- const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
- template &lt;class BidirectionalIterator, class Allocator&gt;
- bool operator!= (const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
- const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
-
-// 28.10.6, match_results swap:
-</pre></blockquote>
-
-<p>
-But the details of these two bool operator functions (i.e., which members of
-<tt>match_results</tt> should be used in comparison) are not described in any
-following sections.
-</p>
-
-<p><i>[
-John adds:
-]</i></p>
-
-
-<blockquote><p>
-That looks like a bug: <tt>operator==</tt> should return <tt>true</tt> only if
-the two objects refer to the same match - ie if one object was constructed as a
-copy of the other.
-</p></blockquote>
-
-<p><i>[
-Kona (2007): Bill and Pete to add minor wording to that proposed in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a new section after 28.10.6 [re.results.swap], which reads:
-</p>
-<p>
-28.10.7 match_results non-member functions.
-</p>
-
-<blockquote>
-<pre>template&lt;class BidirectionalIterator, class Allocator&gt;
- bool operator==(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
- const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>true</tt> only if the two objects refer to the same match.
-</p>
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>template&lt;class BidirectionalIterator, class Allocator&gt;
- bool operator!=(const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
- const match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>!(m1 == m2)</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>template&lt;class BidirectionalIterator, class Allocator&gt;
- void swap(match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m1,
- match_results&lt;BidirectionalIterator, Allocator&gt;&amp; m2);
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>m1.swap(m2)</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-<p><i>[
-Bellevue: Proposed wording now in WP.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="686"></a>686. Unique_ptr and shared_ptr fail to specify non-convertibility to int for unspecified-bool-type</h3>
-<p><b>Section:</b> 20.7.11.2.4 [unique.ptr.single.observers], 20.7.12.2.5 [util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-06-14</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The standard library uses the <tt>operator <i>unspecified-bool-type</i>() const</tt> idiom in
-five places. In three of those places (20.6.15.2.3 [func.wrap.func.cap], function capacity
-for example) the returned value is constrained to disallow
-unintended conversions to int. The standardese is
-</p>
-<blockquote><p>
-The return type shall not be convertible to <tt>int</tt>.
-</p></blockquote>
-<p>
-This constraint is omitted for <tt>unique_ptr</tt> and <tt>shared_ptr</tt>. It should be added for those.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Close as NAD. Accepting paper
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2435.htm">N2435</a>
-makes it irrelevant.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-To the <i>Returns</i> paragraph for <tt>operator <i>unspecified-bool-type</i>()
-const</tt>
-of 20.7.11.2.4 [unique.ptr.single.observers] paragraph 11 and
-20.7.12.2.5 [util.smartptr.shared.obs] paragraph 16, add the sentence:
-</p>
-<blockquote><p>
-The return type shall not be convertible to <tt>int</tt>.
-</p></blockquote>
-
-
-<p><i>[
-Kona (2007): Uncertain if <tt>nullptr</tt> will address this issue.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="690"></a>690. abs(long long) should return long long</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Niels Dekker <b>Date:</b> 2007-06-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Quoting the latest draft (n2135), 26.7 [c.math]:
-</p>
-
-<blockquote>
-<p>
-The added signatures are:
-</p>
-<blockquote><pre>long abs(long); // labs()
-long abs(long long); // llabs()
-</pre></blockquote>
-</blockquote>
-<p>
-Shouldn't <tt>abs(long long)</tt> have <tt>long long</tt> as return type?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.7 [c.math]:
-</p>
-<blockquote><pre><ins>long </ins>long abs(long long); // llabs()
-</pre></blockquote>
-
-
-<p><b>Rationale:</b></p>
-Had already been fixed in the WP by the time the LWG reviewed this.
-
-
-
-
-
-<hr>
-<h3><a name="697"></a>697. New <tt>&lt;system_error&gt;</tt> header leads to name clashes</h3>
-<p><b>Section:</b> 19.4 [syserr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-06-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#syserr">active issues</a> in [syserr].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#syserr">issues</a> in [syserr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The most recent state of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html">N2241</a>
-as well as the current draft
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
-(section 19.4 [syserr], p.2) proposes a
-new
-enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
-the enumerators has the name <tt>invalid_argument</tt>, or fully qualified:
-<tt>std::invalid_argument</tt>. This name clashes with the exception type
-<tt>std::invalid_argument</tt>, see 19.1 [std.exceptions]/p.3. This clash makes
-e.g. the following snippet invalid:
-</p>
-
-<blockquote><pre>#include &lt;system_error&gt;
-#include &lt;stdexcept&gt;
-
-void foo() { throw std::invalid_argument("Don't call us - we call you!"); }
-</pre></blockquote>
-
-<p>
-I propose that this enumeration type (and probably the remaining parts
-of
-<tt>&lt;system_error&gt;</tt> as well) should be moved into one additional inner
-namespace, e.g. <tt>sys</tt> or <tt>system</tt> to reduce foreseeable future clashes
-due
-to the great number of members that <tt>std::posix_errno</tt> already contains
-(Btw.: Why has the already proposed <tt>std::sys</tt> sub-namespace from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2066.html">N2066</a>
-been rejected?). A further clash <em>candidate</em> seems to be
-<tt>std::protocol_error</tt>
-(a reasonable name for an exception related to a std network library,
-I guess).
-</p>
-
-<p>
-Another possible resolution would rely on the proposed strongly typed
-enums,
-as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2213.pdf">N2213</a>.
-But maybe the forbidden implicit conversion to integral types would
-make
-these enumerators less attractive in this special case?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Fixed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2422.htm#Issue7">issue 7 of N2422</a>.
-</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="707"></a>707. null pointer constant for <tt>exception_ptr</tt></h3>
-<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-07-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-From the Toronto Core wiki:
-</p>
-
-<p>
-What do you mean by "null pointer constant"? How do you guarantee that
-<tt>exception_ptr() == 1</tt> doesn't work? Do you even want to prevent that?
-What's the semantics? What about <tt>void *p = 0; exception_ptr() == p</tt>?
-Maybe disallow those in the interface, but how do you do that with
-portable C++? Could specify just "make it work".
-</p>
-
-<p>
-Peter's response:
-</p>
-
-<p>
-null pointer constant as defined in 4.10 [conv.ptr]. Intent is "just make it
-work", can be implemented as assignment operator taking a unique pointer
-to member, as in the unspecified bool type idiom.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Original implementation was possible using the "unspecified-null-pointer" idiom, similar to unspecified-bool.
-</p>
-<p>
-Even simpler now with nullptr_t.
-</p>
-<p>
-NAD Rationale : null pointer constant is a perfectly defined term, and
-while API is clearly implementable there is no need to spell out
-implementation details.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="717"></a>717. Incomplete <tt>valarray::operator[]</tt> specification in [valarray.access]</h3>
-<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-08-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Since the return type of <tt>valarray</tt>'s <tt>operator[] const</tt> overload has been
-changed to <tt>const T&amp;</tt> as described in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> several paragraphs of
-the section 26.5.2.3 [valarray.access] are now
-incompletely
-specified, because many requirements and guarantees should now also
-apply to the const overload. Most notably, the address and reference
-guarantees should be extended to the const overload case.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.5.2.3 [valarray.access]:
-</p>
-
-<blockquote>
-<p>
--1- <del>When applied to a constant array, the subscript operator returns a
-reference to the corresponding element of the array. When applied to a
-non-constant array, t</del><ins>T</ins>he subscript operator returns a
-reference to the corresponding element of the array.
-</p>
-
-<p>
--3- The expression <tt>&amp;a[i+j] == &amp;a[i] + j</tt> evaluates as <tt>true</tt> for all <tt>size_t i</tt>
-and <tt>size_t j</tt> such that <tt>i+j</tt> is less
-than the length of the <del>non-constant</del> array <tt>a</tt>.
-</p>
-
-<p>
--4- Likewise, the expression <tt>&amp;a[i] != &amp;b[j]</tt> evaluates
-as <tt>true</tt> for any two <del>non-constant</del> arrays <tt>a</tt> and
-<tt>b</tt> and for any <tt>size_t i</tt> and <tt>size_t j</tt> such that
-<tt>i</tt> is less than the length of <tt>a</tt> and <tt>j</tt> is less
-than the length of <tt>b</tt>. This property indicates an absence of
-aliasing and may be used to advantage by optimizing
-compilers.<sup>281)</sup>
-</p>
-
-<p>
--5- The reference returned by the subscript operator for a<ins>n</ins> <del>non-constant</del> array is guaranteed to be valid until
-the member function <tt>resize(size_t, T)</tt> (26.5.2.7) is called for that array or until the lifetime
-of that array ends, whichever happens first.
-</p>
-
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="725"></a>725. Optional sequence container requirements column label</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> David Abrahams <b>Date:</b> 2007-09-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Table 90: (Optional sequence container operations) states the
-"assertion note pre/post-condition" of <tt>operator[]</tt> to be
-</p>
-
-<blockquote><pre>*(a.begin() + n)
-</pre></blockquote>
-
-<p>
-Surely that's meant to be "operational semantics?"
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<blockquote>
-<table border="1">
-<caption>Table 90: Optional sequence container operations</caption>
-<tbody><tr>
-<th>expression</th> <th>return type</th> <th><del>assertion/note<br>pre/post-condition</del><br> <ins>operational semantics</ins></th> <th>container</th>
-</tr>
-</tbody></table>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="729"></a>729. Problem in [rand.req.eng]/3</h3>
-<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The 3rd table row in 26.4.1.3 [rand.req.eng]/3 requires random number engines to accept any
-arithmetic type as a seed, which is then casted to the engine's <tt>result_type</tt> and subsequently
-used for seeding the state of the engine. The requirement stated as "Creates an engine with
-initial state determined by <tt>static_cast&lt;X::result_type&gt;(s)</tt>" forces random number engines
-to either use a seeding method that completely depends on the <tt>result_type</tt> (see the discussion
-of seeding for the <tt>mersenne_twister_engine</tt> in point T2 above) or at least to throw away "bits
-of randomness" in the seed value if the <tt>result_type</tt> is smaller than the seed type. This seems
-to be inappropriate for many modern random number generators, in particular F2-linear or
-cryptographic ones, which operate on an internal bit array that in principle is independent of the
-type of numbers returned.
-</p>
-
-<p>
-<b>Posible resolution:</b> I propose to change the wording to a version similar to "Creates an
-engine with initial state determined by <tt>static_cast&lt;UintType&gt;(s)</tt>, where <tt>UintType</tt> is an
-implementation specific unsigned integer type."
-</p>
-
-<p>
-Additionally, the definition of s in 26.4.1.3 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
-</p>
-
-<p>
-Similarly, the type of the seed in 26.4.1.4 [rand.req.adapt]/3 e) could be left unspecified.
-</p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for further discussion.
-</p>
-
-<p><i>[
-Stephan Tolksdorf adds pre-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-In reply to the discussion in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-regarding this issue:
-</p>
-<p>
-The descriptions of all engines and engine adaptors given in sections
-26.4.3 [rand.eng] and 26.4.4 [rand.adapt] already specify the concrete
-types of the integer arguments for seeding. Hence, relaxing the general
-requirement in 26.4.1.3 [rand.req.eng] would not affect portability and
-reproducibility of the standard library. Furthermore, it is not clear to
-me what exactly the guarantee "with initial state determined by
-<tt>static_cast&lt;X::result_type&gt;(s)</tt>" is useful for. On the other hand,
-relaxing the requirement would allow developers to implement other
-random number engines that do not have to cast all arithmetic seed
-arguments to their result_types.
-</p>
-</blockquote>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Propose close NAD for the reasons given in N2424.
-</blockquote>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for further discussion.
-</p>
-
-<p><i>[
-Stephan Tolksdorf adds pre-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Change row 3 of table 105 "Random number engine requirements" in 26.4.1.3 [rand.req.eng]/3
-</p>
-
-<blockquote>
-Creates an engine with initial state determined by
-<tt><del>static_cast&lt;X::result_type&gt;(</del>s<del>)</del></tt>
-</blockquote>
-
-<p>
-Similarly, change 26.4.1.4 [rand.req.adapt]/3 e)
-</p>
-
-<blockquote>
-When <tt>X::X</tt> is invoked with <del>an <tt>X::result_type</tt></del> value <tt>s</tt>
-<ins>of arithmetic type (3.9.1)</ins>, ...
-</blockquote>
-
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="730"></a>730. Comment on [rand.req.adapt]/3 e)</h3>
-<p><b>Section:</b> 26.4.1.4 [rand.req.adapt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-If an engine adaptor is invoked with an argument of type <tt>seed_seq</tt>, then all base
-engines are specified to be seeded with this <tt>seed_seq</tt>. As <tt>seed_seq</tt>'s randomization method is
-qualified as constant, this procedure will ef fectively initialize all base engines with the same seed
-(though the resulting state might still dif fer to a certain degree if the engines are of different types).
-It is not clear whether this mode of operation is in general appropriate, hence -- as far as the
-stated requirements are of general nature and not just specific to the engine adaptors provided by
-the library -- it might be better to leave the behaviour unspecified, since the current definition of
-<tt>seed_seq</tt> does not allow for a generally satisfying specification.
-</p>
-
-<p>
-<b>Posssible resolution:</b> [As above]
-</p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for further discussion.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Close NAD for the reasons given in N2424.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for the proposed resolution.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="731"></a>731. proposal for a customizable <tt>seed_seq</tt></h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The proper way to seed random number engines seems to be the most frequently
-discussed issue of the 26.4 [rand] proposal. While the new <tt>seed_seq</tt> approach is already rather
-general and probably sufficient for most situations, it is unlikely to be optimal in every case (one
-problem was pointed out in point T5 above). In some situations it might, for instance, be better to
-seed the state with a cryptographic generator.
-</p>
-<p>
-In my opinion this is a pretty strong argument for extending the standard with a simple facility to
-customize the seeding procedure. This could, for example, be done with the following minimal
-changes:
-</p>
-
-<p>
-<b>Possible resolution:</b>
-</p>
-
-<ol type="a">
-<li>
-Turn the interface specification of 26.4.7.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the
-exact behaviour of the constructors and the randomize method are left unspecified and where the
-const qualification for randomize is removed. Classes implementing this interface are additionally
-required to specialize the traits class in c).
-</li>
-<li>
-Provide the class <tt>seed_seq</tt> as a default implementation of the SeedSeq interface.
-</li>
-<li>
-<p>
-Supplement the <tt>seed_seq</tt> with a traits class
-</p>
-<blockquote><pre>template &lt;typename T&gt;
-struct is_seed_seq { static const bool value = false; }
-</pre></blockquote>
-<p>and the specialization</p>
-<blockquote><pre>template &lt;&gt;
-struct is_seed_seq&lt;seed_seq&gt; { static const bool value = true; }
-</pre></blockquote>
-<p>which users can supplement with further specializations.</p>
-</li>
-<li>
-Change 26.4.1.3 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and
-modify the constructors and seed methods in 26.4.3 [rand.eng] appropriately (the actual implementation
-could be done using the SFINAE technique).
-</li>
-</ol>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-See N2424. Close NAD but note that "conceptizing" the library may cause
-this problem to be solved by that route.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for the proposed resolution.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="733"></a>733. Comment on [rand.req.dist]/9</h3>
-<p><b>Section:</b> 26.4.1.5 [rand.req.dist] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The requirement "P shall have a declaration of the form <tt>typedef X distribution_-
-type</tt>" effectively makes the use of inheritance for implementing distributions very inconvenient,
-because the child of a distribution class in general will not satisfy this requirement. In my opinion
-the benefits of having a typedef in the parameter class pointing back to the distribution class are
-not worth the hassle this requirement causes. [In my code base I never made use of the nested
-typedef but on several occasions could have profited from being able to use simple inheritance for
-the implementation of a distribution class.]
-</p>
-
-<p>
-<b>Proposed resolution:</b> I propose to drop this requirement.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Close NAD for the reasons given in N2424. In practice it is not inconvenient to meet these requirements.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for the proposed resolution.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="735"></a>735. Unfortunate naming</h3>
-<p><b>Section:</b> 26.4.8.2.2 [rand.dist.bern.bin], 26.4.8.2.4 [rand.dist.bern.negbin] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In my opinion the choice of name for the <tt>t</tt> parameter of the <tt>binomial_distribution</tt>
-is very unfortunate. In virtually every internet reference, book and software implementation
-this parameter is called <tt>n</tt> instead, see for example Wikipedia, Mathworld, Evans et al. (1993)
-Statistical Distributions, 2nd E., Wiley, p. 38, the R statistical computing language, p. 926,
-Mathematica and Matlab.
-</p>
-
-<p>
-Similarly, the choice of <tt>k</tt> for the parameter of the negative binomial distributions is rather unusual.
-The most common choice for the negative binomial distribution seems to be <tt>r</tt> instead.
-</p>
-
-<p>
-Choosing unusual names for the parameters causes confusion among users and makes the
-interface unnecessarily inconvenient to use.
-</p>
-
-<p>
-<b>Possible resolution:</b> For these reasons, I propose to change the name of the respective parameters
-to <tt>n</tt> and <tt>r</tt>.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-In N2424. NAD It has been around for a while. It is hardly universal,
-there is prior art, and this would confuse people.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for the proposed resolution.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="736"></a>736. Comment on [rand.dist.samp.discrete]</h3>
-<p><b>Section:</b> 26.4.8.5.1 [rand.dist.samp.discrete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.discrete">active issues</a> in [rand.dist.samp.discrete].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.discrete">issues</a> in [rand.dist.samp.discrete].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<ol type="a">
-<li>
-The specification for <tt>discrete_distribution</tt> requires the member <tt>probabilities()</tt>
-to return a vector of <i>standardized</i> probabilities, which forces the implementation every time to
-divide each probability by the sum of all probabilities, as the sum will in practice almost never be
-exactly 1.0. This is unnecessarily inef ficient as the implementation would otherwise not need to
-compute the standardized probabilities at all and could instead work with the non-standardized
-probabilities and the sum. If there was no standardization the user would just get back the
-probabilities that were previously supplied to the distribution object, which to me seems to be the
-more obvious solution.
-</li>
-<li>
-The behaviour of <tt>discrete_distribution</tt> is not specified in case the number of given
-probabilities is larger than the maximum number representable by the IntType.
-</li>
-</ol>
-
-<p>
-<b>Possible resolution:</b> I propose to change the specification such that the non-standardized
-probabilities need to be returned and that an additional requirement is included for the number
-of probabilities to be smaller than the maximum of IntType.
-</p>
-
-<p><i>[
-Stephan Tolksdorf adds pre-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-In reply to the discussion in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-of this issue:
-</p>
-<p>
-Rescaled floating-point parameter vectors can not be expected to compare
-equal because of the limited precision of floating-point numbers.
-My proposal would at least guarantee that a parameter
-vector (of type double) passed into the distribution would compare equal
-with the one returned by the <tt>probabilities()</tt> method. Furthermore, I do
-not understand why "the changed requirement would lead to a significant
-increase in the amount of state in the distribution object". A typical
-implementation's state would increase by exactly one number: the sum of
-all probabilities. The textual representation for serialization would
-not need to grow at all. Finally, the proposed replacement "<tt>0 &lt; n &lt;=
-numeric_limits&lt;IntType&gt;::max() + 1</tt>" makes the implementation
-unnecessarily complicated, "<tt>0 &lt; n &lt;= numeric_limits&lt;IntType&gt;::max()</tt>"
-would be better.
-</p>
-</blockquote>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-In N2424. We agree with the observation and the proposed resolution to
-part b). We recommend the wording n &gt; 0 be replaced with 0 &lt; n
-numeric_limits::max() + 1. However, we disagree with part a), as it
-would interfere with the definition of parameters' equality. Further,
-the changed requirement would lead to a significant increase in the
-amount of state of the distribution object.
-</p>
-
-<p>
-As it stands now, it is convenient, and the changes proposed make it
-much less so.
-</p>
-
-<p>
-NAD. Part a the current behavior is desirable. Part b, any constructor
-can fail, but the rules under which it can fail do not need to be listed
-here.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for the proposed resolution.
-</p>
-
-<p><i>[
-Stephan Tolksdorf adds pre-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-In 26.4.8.5.1 [rand.dist.samp.discrete]:
-</p>
-
-<p>
-Proposed wording a):
-</p>
-
-<blockquote>
-<p>
-Changae in para. 2
-</p>
-
-<blockquote>
-Constructs a <tt>discrete_distribution</tt> object with <tt>n=1</tt> and <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt>
-</blockquote>
-
-<p>
-and change in para. 5
-</p>
-
-<blockquote>
-<i>Returns:</i> A <tt>vector&lt;double&gt;</tt> whose <tt>size</tt> member returns <tt>n</tt> and whose
-<tt>operator[]</tt> member returns <del><tt>p<sub>k</sub></tt></del>
-<ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins>
-when invoked with argument <tt>k</tt> for <tt>k = 0,
-..., n-1</tt>
-</blockquote>
-
-</blockquote>
-
-<p>
-Proposed wording b):
-</p>
-
-<blockquote>
-<p>
-Change in para. 3:
-</p>
-
-<blockquote>
-If <tt>firstW == lastW</tt>, let the sequence <tt>w</tt> have length <tt>n = 1</tt> and consist
-of the single value <tt>w<sub>0</sub> = 1</tt>. Otherwise, <tt>[firstW,lastW)</tt> shall form a
-sequence <tt>w</tt> of length <tt>n <del>&gt; 0</del></tt>
-<ins>such that <tt>0 &lt; n &lt;= numeric_limits&lt;IntType&gt;::max()</tt>,</ins>
-and <tt>*firstW</tt> shall yield a value <tt>w<sub>0</sub></tt>
-convertible to <tt>double</tt>. [<i>Note:</i> The values <tt>w<sub>k</sub></tt> are commonly known
-as the weights . <i>-- end note</i>]
-</blockquote>
-
-</blockquote>
-
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="737"></a>737. Comment on [rand.dist.samp.pconst]</h3>
-<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<ol type="a">
-<li>
-The discussion in point T11 above regarding <tt>probabilities()</tt> similarly applies
-to the method <tt>densities()</tt> of <tt>piecewise_constant_distribution</tt>.
-</li>
-<li>
-<p>
-The design of the constructor
-</p>
-<blockquote><pre>template &lt;class InputIteratorB, class InputIteratorW&gt;
-piecewise_constant_distribution( InputIteratorB firstB, InputIteratorB lastB,
- InputIteratorW firstW);
-</pre></blockquote>
-<p>
-is unnecessarily unsafe, as there is no separate end-iterator given for the weights. I can't see
-any performance or convenience reasons that would justify the risks inherent in such a function
-interface, in particular the risk that input error might go unnoticed.
-</p>
-</li>
-</ol>
-
-<p>
-<b>Possible resolution:</b> I propose to add an <tt>InputIteratorW lastW</tt> argument to the interface.
-</p>
-
-<p><i>[
-Stephan Tolksdorf adds pre-Bellevue:
-]</i></p>
-
-<blockquote>
-In reply to the discussion in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-I'd like to make the same comments as for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>.
-</blockquote>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-In N2424. There is already precedent elsewhere in the library. Follows existing convention. NAD.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for the proposed resolution.
-</p>
-
-<p><i>[
-Stephan Tolksdorf adds pre-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-In 26.4.8.5.2 [rand.dist.samp.pconst]:
-</p>
-
-<p>
-Proposed wording a)
-</p>
-
-<blockquote>
-<p>
-Change in para. 2
-</p>
-<blockquote>
-Constructs a <tt>piecewise_constant_distribution</tt> object with <tt>n = 1</tt>, <tt>p<sub>0</sub> <ins>= w<sub>0</sub></ins> = 1</tt>,
-<tt>b<sub>0</sub> = 0</tt>, and <tt>b<sub>1</sub> = 1</tt>
-</blockquote>
-
-<p>
-and change in para. 5
-</p>
-
-<blockquote>
-A <tt>vector&lt;result_type&gt;</tt> whose <tt>size</tt> member returns <tt>n</tt> and whose <tt>operator[]</tt>
-member returns <del><tt>p<sub>k</sub></tt></del>
-<ins>the weight <tt>w<sub>k</sub></tt> as a double value</ins>
-when invoked with argument <tt>k</tt> for <tt>k = 0, ..., n-1</tt>
-</blockquote>
-
-</blockquote>
-
-<p>
-Proposed wording b)
-</p>
-
-<blockquote>
-<p>
-Change both occurrences of
-</p>
-
-<blockquote>
-"piecewise_constant_distribution(InputIteratorB firstB, InputIteratorB lastB,
- InputIteratorW firstW<ins>, InputIteratorW lastW</ins>)
-</blockquote>
-
-<p>
-and change in para. 3
-</p>
-
-<blockquote>
-<del>the length of the sequence <tt>w</tt> starting from <tt>firstW</tt> shall be at least <tt>n</tt>,
-<tt>*firstW</tt> shall return a value <tt>w<sub>0</sub></tt> that is convertible to <tt>double</tt>, and any
-<tt>w<sub>k</sub></tt> for <tt>k &gt;= n</tt> shall be ignored by the distribution</del>
-<ins><tt>[firstW, lastW)</tt> shall form a sequence <tt>w</tt> of length <tt>n</tt> whose leading element
-<tt>w<sub>0</sub></tt> shall be convertible to <tt>double</tt></ins>
-</blockquote>
-
-</blockquote>
-
-
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="738"></a>738. Editorial issue in [rand.adapt.disc]/3</h3>
-<p><b>Section:</b> 26.4.4.1 [rand.adapt.disc] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">Pending NAD Editorial</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Pending%20NAD%20Editorial">Pending NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Since the template parameter <tt>p</tt> and <tt>r</tt> are of type <tt>size_t</tt>, the member <tt>n</tt> in the class
-exposition should have type <tt>size_t</tt>, too.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for the proposed resolution.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="739"></a>739. Defect in [rand.util.canonical]/3</h3>
-<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2007-09-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The complexity of <tt>generate_canonical</tt> is specified to be "exactly k=max(1, ceil(b/log2
-R)) invocations of g". This terms involves a logarithm that is not rounded and hence can not (in
-general) be computed at compile time. As this function template is performance critical, I propose
-to replace ceil(b/log2 R) with ceil(b/floor(log2 R)).
-</p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for further discussion.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-In N2424. Close NAD as described there.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2424.pdf">N2424</a>
-for the proposed resolution.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="741"></a>741. Const-incorrect <tt>get_deleter</tt> function for <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-09-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The following issue was raised by Alf P. Steinbach in c.l.c++.mod:
-</p>
-
-<p>
-According to the recent draft N2369, both the header memory synopsis
-of 20.7 [memory] and 20.7.12.2.11 [util.smartptr.getdeleter] declare:
-</p>
-
-<blockquote><pre>template&lt;class D, class T&gt; D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
-</pre></blockquote>
-
-<p>
-This allows to retrieve the pointer to a mutable deleter of a <tt>const
-shared_ptr</tt> (if that owns one) and therefore contradicts the usual
-philosophy that associated functors are either read-only (e.g.
-<tt>key_comp</tt> or <tt>value_comp</tt> of <tt>std::map</tt>) or do at least reflect
-the mutability of the owner (as seen for the both overloads of
-<tt>unique_ptr::get_deleter</tt>).
-Even the next similar counter-part of <tt>get_deleter</tt> - the two
-overloads of <tt>function::target</tt> in the class template function
-synopsis 20.6.15.2 [func.wrap.func] or in 20.6.15.2.5 [func.wrap.func.targ] - do
-properly mirror the const-state of the owner.
-</p>
-
-<b>Possible proposed resolutions:</b>
-
-<p>
-Replace the declarations of <tt>get_deleter</tt> in the header <tt>&lt;memory&gt;</tt>
-synopsis of 20.7 [memory] and in 20.7.12.2.11 [util.smartptr.getdeleter] by one of the
-following alternatives (A) or (B):
-</p>
-
-<ol type="A">
-<li>
-Provide <b>only</b> the immutable variant. This would reflect the
-current praxis of <tt>container::get_allocator()</tt>, <tt>map::key_comp()</tt>, or
-<tt>map::value_comp</tt>.
-
-<blockquote><pre>template&lt;class D, class T&gt; const D* get_deleter(shared_ptr&lt;T&gt; const&amp; p);
-</pre></blockquote>
-</li>
-<li>
-Just remove the function.
-</li>
-</ol>
-
-<p>
-Alberto Ganesh Barbati adds:
-</p>
-
-<ol start="3" type="A">
-<li>
-<p>
-Replace it with two functions:
-</p>
-<blockquote><pre>template &lt;class D, class T&gt; D get_deleter(shared_ptr&lt;T&gt; const&amp;);
-template &lt;class D, class T&gt; bool has_deleter(shared_ptr&lt;T&gt; const&amp;);
-</pre></blockquote>
-
-<p>
-The first one would throw if <tt>D</tt> is the wrong type, while the latter would
-never throw. This approach would reflect the current praxis of
-<tt>use_facet/has_facet</tt>, with the twist of returning the deleter by value as
-<tt>container::get_allocator()</tt> do.
-</p>
-</li>
-</ol>
-
-<p>
-Peter Dimov adds:
-</p>
-
-<blockquote>
-<p>
-My favorite option is "not a defect". A, B and C break useful code.
-</p>
-</blockquote>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Concern this is similar to confusing "pointer to const" with "a constant pointer".
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="745"></a>745. copy_exception API slices.</h3>
-<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It could be I did not understand the design rationale, but I thought
-copy_exception would produce an exception_ptr to the most-derived (dynamic)
-type of the passed exception. Instead it slices, which appears to be less
-useful, and a likely source of FAQ questions in the future.
-</p>
-<p>
-(Peter Dimov suggests NAD)
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-How could this be implemented in a way that the dynamic type is cloned?
-</p>
-<p>
-The feature is designed to create an exception_ptr from an object whose
-static type is identical to the dynamic type and thus there is no
-slicing involved.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="748"></a>748. The is_abstract type trait is defined by reference to 10.4.</h3>
-<p><b>Section:</b> 20.5.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I am trying to decide is a pure virtual function is a <i>necessary</i> as well as
-sufficient requirement to be classified as abstract?
-</p>
-<p>
-For instance, is the following (non-polymorphic) type considered abstract?
-</p>
-<blockquote><pre>struct abstract {
-protected:
-&nbsp;abstract(){}
-&nbsp;abstract( abstract const &amp; ) {}
-&nbsp;~abstract() {}
-};
-</pre></blockquote>
-<p>
-(Suggested that this may be NAD, with an editorial fix-up from Pete on the
-core wording to make clear that abstract requires a pure virtual function)
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Core has clarified that the definition abstract is adequate. Issue withdrawn by submitter. NAD.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="754"></a>754. Ambiguous return clause for <tt>std::uninitialized_copy</tt></h3>
-<p><b>Section:</b> 20.7.10.1 [uninitialized.copy] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-10-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-14882-2003, [lib.uninitialized.copy] is currently written as follows:
-</p>
-
-<blockquote>
-<pre>template &lt;class InputIterator, class ForwardIterator&gt;
- ForwardIterator uninitialized_copy(InputIterator <i>first</i>, InputIterator <i>last</i>,
- ForwardIterator <i>result</i>);
-</pre>
-<blockquote>
-<p>
--1- <i>Effects:</i>
-</p>
-<blockquote><pre>for (; first != last; ++result, ++first)
- new (static_cast&lt;void*&gt;(&amp;*result))
- typename iterator_traits&lt;ForwardIterator&gt;::value_type(*first);
-</pre></blockquote>
-<p>
--2- <i>Returns:</i> <tt><i>result</i></tt>
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-similarily for N2369, and its corresponding section
-20.7.10.1 [uninitialized.copy].
-</p>
-
-<p>
-It's not clear to me what the return clause is supposed to mean, I see
-two
-possible interpretations:
-</p>
-
-<ol type="a">
-<li>
-The notion of <tt><i>result</i></tt> is supposed to mean the value given by the
-function parameter <tt><i>result</i></tt> [Note to the issue editor: Please use italics for
-<tt><i>result</i></tt>].
-This seems somewhat implied by recognizing that both the function
-parameter
-and the name used in the clause do have the same italic font.
-</li>
-<li>
-The notion of "result" is supposed to mean the value of <tt><i>result</i></tt>
-after the
-preceding effects clause. This is in fact what all implementations I
-checked
-do (and which is probably it's intend, because it matches the
-specification of <tt>std::copy</tt>).
-</li>
-</ol>
-
-<p>
-The problem is: I see nothing in the standard which grants that this
-interpretation
-is correct, specifically [lib.structure.specifications] or
-17.3.1.3 [structure.specifications]
-resp. do not clarify which "look-up" rules apply for names found in
-the elements
-of the detailed specifications - Do they relate to the corresponding
-synopsis or
-to the effects clause (or possibly other elements)? Fortunately most
-detailed
-descriptions are unambigious in this regard, e.g. this problem does
-not apply
-for <tt>std::copy</tt>.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the wording of the return clause to say (20.7.10.1 [uninitialized.copy]):
-</p>
-
-<blockquote>
-<p>
--2- <i>Returns:</i> <ins>The value of</ins> <tt><i>result</i></tt> <ins>after effects have taken place.</ins>
-</p>
-</blockquote>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Resolution: NAD editorial -- project editor to decide if change is
-worthwhile. Concern is that there are many other places this might
-occur.
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="756"></a>756. Container adaptors push</h3>
-<p><b>Section:</b> 23.2.5 [container.adaptors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-10-31</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-After n2369 we have a single <tt>push_back</tt> overload in the sequence containers,
-of the "emplace" type. At variance with that, still in n2461, we have
-two separate overloads, the C++03 one + one taking an rvalue reference
-in the container adaptors. Therefore, simply from a consistency point of
-view, I was wondering whether the container adaptors should be aligned
-with the specifications of the sequence container themselves: thus have
-a single <tt>push</tt> along the lines:
-</p>
-
-<blockquote><pre>template&lt;typename... _Args&gt;
-void
-push(_Args&amp;&amp;... __args)
- { c.push_back(std::forward&lt;_Args&gt;(__args)...); }
-</pre></blockquote>
-
-<p><i>[
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 23.2.5.1.1 [queue.defn]:
-</p>
-
-<blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
-<del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
-<ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
-</pre></blockquote>
-
-<p>
-Change 23.2.5.2 [priority.queue]:
-</p>
-
-<blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
-<del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
-<ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
-</pre></blockquote>
-
-<p>
-Change 23.2.5.2.2 [priqueue.members]:
-</p>
-
-<blockquote>
-<pre><del>void push(const value_type&amp; x);</del>
-</pre>
-<blockquote>
-<p>
-<del><i>Effects:</i></del>
-</p>
-<blockquote><pre><del>c.push_back(x);</del>
-<del>push_heap(c.begin(), c.end(), comp);</del>
-</pre></blockquote>
-</blockquote>
-
-<pre><ins>template&lt;class... Args&gt;</ins> void push(<del>value_type</del> <ins>Args</ins>&amp;&amp;<ins>...</ins> <del>x</del> <ins>args</ins>);
-</pre>
-<blockquote>
-<p>
-<i>Effects:</i>
-</p>
-<blockquote><pre>c.push_back(std::<del>move</del><ins>forward&lt;Args&gt;</ins>(<del>x</del> <ins>args</ins>)<ins>...</ins>);
-push_heap(c.begin(), c.end(), comp);
-</pre></blockquote>
-</blockquote>
-</blockquote>
-
-<p>
-Change 23.2.5.3.1 [stack.defn]:
-</p>
-
-<blockquote><pre><del>void push(const value_type&amp; x) { c.push_back(x); }</del>
-<del>void push(value_type&amp;&amp; x) { c.push_back(std::move(x)); }</del>
-<ins>template&lt;class... Args&gt; void push(Args&amp;&amp;... args) { c.push_back(std::forward&lt;Args&gt;(args)...); }</ins>
-</pre></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Addressed by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="757"></a>757. Typo in the synopsis of vector</h3>
-<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2007-11-04</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In the synopsis 23.2.6 [vector], there is the signature:
-</p>
-
-<blockquote><pre>void insert(const_iterator position, size_type n, T&amp;&amp; x);
-</pre></blockquote>
-
-<p>
-instead of:
-</p>
-
-<blockquote><pre>iterator insert(const_iterator position, T&amp;&amp; x);
-</pre></blockquote>
-
-<p>
-23.2.6.4 [vector.modifiers] is fine.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 23.2.6 [vector]:
-</p>
-
-<blockquote><pre>iterator insert(const_iterator position, const T&amp; x);
-<ins>iterator insert(const_iterator position, T&amp;&amp; x);</ins>
-void insert(const_iterator position, size_type n, const T&amp; x);
-<del>void insert(const_iterator position, size_type n, T&amp;&amp; x);</del>
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="763"></a>763. Renaming <tt>emplace()</tt> overloads</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-04</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The associative containers provide 2 overloads of <tt>emplace()</tt>:
-</p>
-
-<blockquote><pre>template &lt;class... Args&gt; pair&lt;iterator, bool&gt; emplace(Args&amp;&amp;... args);
-template &lt;class... Args&gt; iterator emplace(const_iterator position, Args&amp;&amp;... args);
-</pre></blockquote>
-
-<p>
-This is a problem if you mean the first overload while passing
-a <tt>const_iterator</tt> as first argument.
-</p>
-
-<p><i>[
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>
-]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-</blockquote>
-<p>
-This can be disambiguated by passing "begin" as the first argument in
-the case when the non-default choice is desired. We believe that desire
-will be rare.
-</p>
-<p>
-Resolution: Change state to NAD.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Rename one of the two overloads.
-For example to <tt>emplace_here</tt>, <tt>hint_emplace</tt>...
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="764"></a>764. <tt>equal_range</tt> on unordered containers should return a <tt>pair</tt> of <tt>local_iterators</tt></h3>
-<p><b>Section:</b> 23.1.5 [unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-29</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
- A major attribute of the unordered containers is that iterating
-though them inside a bucket is very fast while iterating between buckets
-can be much slower. If an unordered container has a low load factor,
-iterating between the last iterator in one bucket and the next iterator,
-which is in another bucket, is <tt>O(bucket_count())</tt> which may be much
-larger than <tt>O(size())</tt>.
-</p>
-<p>
- If <tt>b</tt> is an non-const unordered container of type <tt>B</tt> and <tt>k</tt> is an
-object of it's <tt>key_type</tt>, then <tt>b.equal_range(k)</tt> currently returns
-<tt>pair&lt;B::iterator, B::iterator&gt;</tt>. Consider the following code:
-</p>
-
-<blockquote><pre>B::iterator lb, ub;
-tie(lb, ub) = b.equal_range(k);
-for (B::iterator it = lb; it != ub; ++it) {
- // Do something with *it
-}
-</pre></blockquote>
-
-<p>
-If <tt>b.equal_range(k)</tt> returns a non-empty range (i.e. <tt>b</tt> contains at least
-on element whose key is equivalent to <tt>k</tt>), then every iterator in the
-half-open range <tt>[lb, ub)</tt> will be in the same bucket, but <tt>ub</tt> will likely
-either be in a different bucket or be equal to <tt>b.end()</tt>. In either case,
-iterating between <tt>ub - 1</tt> and <tt>ub</tt> could take a much longer time than
-iterating through the rest of the range.
-</p>
-<p>
-If instead of returning <tt>pair&lt;iterator, iterator&gt;</tt>, <tt>equal_range</tt> were to
-return <tt>pair&lt;local_iterator, local_iterator&gt;</tt>, then <tt>ub</tt> (which, like <tt>lb</tt>,
-would now be a <tt>local_iterator</tt>) could be guaranteed to always be in the
-same bucket as <tt>lb</tt>. In the cases where currently <tt>ub</tt> is equal to <tt>b.end()</tt>
-or is in a different bucket, <tt>ub</tt> would be equal to <tt>b.end(b.bucket(key))</tt>.
- This would make iterating between <tt>lb</tt> and <tt>ub</tt> much faster, as every
-iteration would be constant time.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-The proposed resolution breaks consistency with other container types
-for dubious benefit, and iterators are already constant time.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the entry for <tt>equal_range</tt> in Table 93 (23.1.5 [unord.req]) as follows:
-</p>
-<table border="1">
-<tbody><tr>
-<th>expression</th> <th>return type</th> <th>assertion/note pre/post-condition</th> <th>complexity</th>
-</tr>
-
-<tr>
-<td><tt>b.equal_range(k)</tt></td>
-<td><tt>pair&lt;<ins>local_</ins>iterator,<ins>local_</ins>iterator&gt;; pair&lt;const_<ins>local_</ins>iterator,const_<ins>local_</ins>iterator&gt;</tt> for <tt>const b</tt>.</td>
-<td>Returns a range containing all elements with keys equivalent to <tt>k</tt>. Returns <tt>make_pair(b.end(<ins>b.bucket(key)</ins>),b.end(<ins>b.bucket(key)</ins>))</tt> if no such elements exist.</td>
-<td>Average case &#920;<tt>(b.count(k))</tt>. Worst case &#920;<tt>(b.size())</tt>. </td>
-</tr>
-</tbody></table>
-
-
-
-
-
-<hr>
-<h3><a name="767"></a>767. Forwarding and backward compatibility</h3>
-<p><b>Section:</b> 23 [containers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Sylvain Pion <b>Date:</b> 2007-12-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#containers">active issues</a> in [containers].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#containers">issues</a> in [containers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Playing with g++'s C++0X mode, I noticed that the following
-code, which used to compile:
-</p>
-
-<blockquote><pre>#include &lt;vector&gt;
-
-int main()
-{
- std::vector&lt;char *&gt; v;
- v.push_back(0);
-}
-</pre></blockquote>
-
-<p>
-now fails with the following error message:
-</p>
-
-<blockquote>.../include/c++/4.3.0/ext/new_allocator.h: In member
-function 'void __gnu_cxx::new_allocator&lt;_Tp&gt;::construct(_Tp*,
-_Args&amp;&amp; ...) [with _Args = int, _Tp = char*]':
-.../include/c++/4.3.0/bits/stl_vector.h:707: instantiated from 'void
-std::vector&lt;_Tp, _Alloc&gt;::push_back(_Args&amp;&amp; ...) [with
-_Args = int, _Tp = char*, _Alloc = std::allocator&lt;char*&gt;]'
-test.cpp:6: instantiated from here
-.../include/c++/4.3.0/ext/new_allocator.h:114: error: invalid
-conversion from 'int' to 'char*'
-</blockquote>
-
-<p>
-As far as I know, g++ follows the current draft here.
-</p>
-<p>
-Does the committee really intend to break compatibility for such cases?
-</p>
-
-<p><i>[
-Sylvain adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-I just noticed that <tt>std::pair</tt> has the same issue.
-The following now fails with GCC's -std=c++0x mode:
-</p>
-
-<blockquote><pre>#include &lt;utility&gt;
-
-int main()
-{
- std::pair&lt;char *, char *&gt; p (0,0);
-}
-</pre></blockquote>
-
-<p>
-I have not made any general audit for such problems elsewhere.
-</p>
-</blockquote>
-
-<p><i>[
-Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>
-]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Motivation is to handle the old-style int-zero-valued NULL pointers.
-Problem: this solution requires concepts in some cases, which some users
-will be slow to adopt. Some discussion of alternatives involving
-prohibiting variadic forms and additional library-implementation
-complexity.
-</p>
-<p>
-Discussion of "perfect world" solutions, the only such solution put
-forward being to retroactively prohibit use of the integer zero for a
-NULL pointer. This approach was deemed unacceptable given the large
-bodies of pre-existing code that do use integer zero for a NULL pointer.
-</p>
-<p>
-Another approach is to change the member names. Yet another approach is
-to forbid the extension in absence of concepts.
-</p>
-<p>
-Resolution: These issues (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>) will be subsumed into a
-paper to be produced by Alan Talbot in time for review at the 2008
-meeting in France. Once this paper is produced, these issues will be
-moved to NAD.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following rows to Table 90 "Optional sequence container operations", 23.1.3 [sequence.reqmts]:
-</p>
-
-<blockquote>
-<table border="1">
-<tbody><tr>
-<th>expression</th> <th>return type</th> <th>assertion/note<br>pre-/post-condition</th> <th>container</th>
-</tr>
-
-<tr>
-<td>
-<tt>a.push_front(t)</tt>
-</td>
-<td>
-<tt>void</tt>
-</td>
-<td>
-<tt>a.insert(a.begin(), t)</tt><br>
-<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
-</td>
-<td>
-<tt>list, deque</tt>
-</td>
-</tr>
-
-<tr>
-<td>
-<tt>a.push_front(rv)</tt>
-</td>
-<td>
-<tt>void</tt>
-</td>
-<td>
-<tt>a.insert(a.begin(), rv)</tt><br>
-<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
-</td>
-<td>
-<tt>list, deque</tt>
-</td>
-</tr>
-
-<tr>
-<td>
-<tt>a.push_back(t)</tt>
-</td>
-<td>
-<tt>void</tt>
-</td>
-<td>
-<tt>a.insert(a.end(), t)</tt><br>
-<i>Requires:</i> <tt>T</tt> shall be <tt>CopyConstructible</tt>.
-</td>
-<td>
-<tt>list, deque, vector, basic_string</tt>
-</td>
-</tr>
-
-<tr>
-<td>
-<tt>a.push_back(rv)</tt>
-</td>
-<td>
-<tt>void</tt>
-</td>
-<td>
-<tt>a.insert(a.end(), rv)</tt><br>
-<i>Requires:</i> <tt>T</tt> shall be <tt>MoveConstructible</tt>.
-</td>
-<td>
-<tt>list, deque, vector, basic_string</tt>
-</td>
-</tr>
-
-</tbody></table>
-</blockquote>
-
-<p>
-Change the synopsis in 23.2.2 [deque]:
-</p>
-
-<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
-<ins>void push_front(T&amp;&amp; x);</ins>
-<ins>void push_back(const T&amp; x);</ins>
-<ins>void push_back(T&amp;&amp; x);</ins>
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
-</pre></blockquote>
-
-<p>
-Change 23.2.2.3 [deque.modifiers]:
-</p>
-
-<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
-<ins>void push_front(T&amp;&amp; x);</ins>
-<ins>void push_back(const T&amp; x);</ins>
-<ins>void push_back(T&amp;&amp; x);</ins>
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
-</pre></blockquote>
-
-<p>
-Change the synopsis in 23.2.4 [list]:
-</p>
-
-<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
-<ins>void push_front(T&amp;&amp; x);</ins>
-<ins>void push_back(const T&amp; x);</ins>
-<ins>void push_back(T&amp;&amp; x);</ins>
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
-</pre></blockquote>
-
-<p>
-Change 23.2.4.3 [list.modifiers]:
-</p>
-
-<blockquote><pre><ins>void push_front(const T&amp; x);</ins>
-<ins>void push_front(T&amp;&amp; x);</ins>
-<ins>void push_back(const T&amp; x);</ins>
-<ins>void push_back(T&amp;&amp; x);</ins>
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_front(Args&amp;&amp;... args);
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
-</pre></blockquote>
-
-<p>
-Change the synopsis in 23.2.6 [vector]:
-</p>
-
-<blockquote><pre><ins>void push_back(const T&amp; x);</ins>
-<ins>void push_back(T&amp;&amp; x);</ins>
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
-</pre></blockquote>
-
-<p>
-Change 23.2.6.4 [vector.modifiers]:
-</p>
-
-<blockquote><pre><ins>void push_back(const T&amp; x);</ins>
-<ins>void push_back(T&amp;&amp; x);</ins>
-template &lt;class... Args&gt; <ins>requires Constructible&lt;T, Args&amp;&amp;...&gt;</ins> void push_back(Args&amp;&amp;... args);
-</pre></blockquote>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Addressed by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2680.pdf">N2680 Proposed Wording for Placement Insert (Revision 1)</a>.
-</p>
-
-<p>
-If there is still an issue with pair, Howard should submit another issue.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="773"></a>773. issues with random</h3>
-<p><b>Section:</b> 26.4.8.1 [rand.dist.uni] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-01-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.uni">issues</a> in [rand.dist.uni].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<ol>
-<li>
-26.4.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> constructor has changed the default
-max constructor parameter from 9 (in TR1) to <tt>max()</tt>. The value
-is arbitrary at best and shouldn't be lightly changed because
-it breaks backward compatibility.
-</li>
-
-<li>
-26.4.8.1.1 [rand.dist.uni.int] <tt>uniform_int</tt> has a parameter <tt>param</tt> that you can
-provide on construction or <tt>operator()</tt>, set, and get. But there
-is not even a hint of what this might be for.
-</li>
-
-<li>
-26.4.8.1.2 [rand.dist.uni.real] <tt>uniform_real</tt>. Same issue as #2.
-</li>
-</ol>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-NAD. Withdrawn.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="784"></a>784. unique_lock::release</h3>
-<p><b>Section:</b> 30.3.3.2.3 [thread.lock.unique.mod] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Constantine Sapuntzakis <b>Date:</b> 2008-02-02</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>unique_lock::release</tt> will probably lead to many mistakes where people
-call <tt>release</tt> instead of <tt>unlock</tt>. I just coded such a mistake using the
-boost pre-1.35 threads library last week.
-</p>
-
-<p>
-In many threading libraries, a call with <tt>release</tt> in it unlocks the
-lock (e.g. ReleaseMutex in Win32, java.util.concurrent.Semaphore).
-</p>
-
-<p>
-I don't call <tt>unique_lock::lock</tt> much at all, so I don't get to see the
-symmetry between <tt>::lock</tt> and <tt>::unlock</tt>. I usually use the constructor to
-lock the mutex. So I'm left to remember whether to call <tt>release</tt> or
-<tt>unlock</tt> during the few times I need to release the mutex before the scope
-ends. If I get it wrong, the compiler doesn't warn me.
-</p>
-
-<p>
-An alternative name for release may be <tt>disown</tt>.
-</p>
-
-<p>
-This might be a rare case where usability is hurt by consistency with
-the rest of the C++ standard (e.g. <tt>std::auto_ptr::release</tt>).
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Change a name from release to disown. However prior art uses the release
-name. Compatibility with prior art is more important that any possible
-benefit such a change might make. We do not see the benefit for
-changing. NAD
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 30.3.3.2 [thread.lock.unique]:
-</p>
-
-<blockquote><pre>template &lt;class Mutex&gt;
-class unique_lock
-{
-public:
- ...
- mutex_type* <del>release</del> <ins>disown</ins>();
- ...
-};
-</pre></blockquote>
-
-<p>
-Change 30.3.3.2.3 [thread.lock.unique.mod]:
-</p>
-
-<blockquote><pre>mutex_type *<del>release</del> <ins>disown</ins>();
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="786"></a>786. Thread library timed waits, UTC and monotonic clocks</h3>
-<p><b>Section:</b> X [datetime.system] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Christopher Kohlhoff, Jeff Garland <b>Date:</b> 2008-02-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The draft C++0x thread library requires that the time points of type
-<tt>system_time</tt> and returned by <tt>get_system_time()</tt> represent Coordinated
-Universal Time (UTC) (section X [datetime.system]). This can lead to
-surprising behavior when a library user performs a duration-based wait,
-such as <tt>condition_variable::timed_wait()</tt>. A complete explanation of the
-problem may be found in the
-<a href="http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html#tag_03_02_08_19">Rationale for the Monotonic Clock</a>
-section in POSIX, but in summary:
-</p>
-
-<ul>
-<li>
-Operations such as <tt>condition_variable::timed_wait()</tt> (and its POSIX
-equivalent, <tt>pthread_cond_timedwait()</tt>) are specified using absolute times
-to address the problem of spurious wakeups.
-</li>
-
-<li>
-The typical use of the timed wait operations is to perform a relative
-wait. This may be achieved by first calculating an absolute time as the
-sum of the current time and the desired duration. In fact, the C++0x
-thread library includes duration-based overloads of
-<tt>condition_variable::timed_wait()</tt> that behave as if by calling the
-corresponding absolute time overload with a time point value of
-<tt>get_system_time() + rel_time</tt>.
-</li>
-
-<li>
-A UTC clock may be affected by changes to the system time, such as
-synchronization with an external source, leap seconds, or manual changes
-to the clock.
-</li>
-
-<li>
-Should the clock change during a timed wait operation, the actual
-duration of the wait will not be the expected length. For example, a
-user may intend a timed wait of one second duration but, due to an
-adjustment of the system clock backwards by a minute, the wait instead
-takes 61 seconds.
-</li>
-</ul>
-
-<p>
-POSIX solves the problem by introducing a new monotonic clock, which is
-unaffected by changes to the system time. When a condition variable is
-initialized, the user may specify whether the monotonic clock is to be
-used. (It is worth noting that on POSIX systems it is not possible to
-use <tt>condition_variable::native_handle()</tt> to access this facility, since
-the desired clock type must be specified during construction of the
-condition variable object.)
-</p>
-
-<p>
-In the context of the C++0x thread library, there are added dimensions
-to the problem due to the need to support platforms other than POSIX:
-</p>
-
-<ul>
-<li>
-Some environments (such as embedded systems) do not have a UTC clock, but do have a monotonic clock.
-</li>
-
-<li>
-Some environments do not have a monotonic clock, but do have a UTC clock.
-</li>
-
-<li>
-The Microsoft Windows API's synchronization functions use relative
-timeouts based on an implied monotonic clock. A program that switches
-from the Windows API to the C++0x thread library will now find itself
-susceptible to clock changes.
-</li>
-</ul>
-
-<p>
-One possible minimal solution:
-</p>
-
-<ul>
-<li>
-Strike normative references to UTC and an epoch based on 1970-01-01.
-</li>
-
-<li>
-Make the semantics of <tt>system_time</tt> and <tt>get_system_time()</tt>
-implementation-defined (i.e standard library implementors may choose the
-appropriate underlying clock based on the capabilities of the target
-platform).
-</li>
-
-<li>
-Add a non-normative note encouraging use of a monotonic clock.
-</li>
-
-<li>
-Remove <tt>system_time::seconds_since_epoch()</tt>.
-</li>
-
-<li>
-Change the constructor <tt>explicit system_time(time_t secs, nanoseconds ns
-= 0)</tt> to <tt>explicit system_time(nanoseconds ns)</tt>.
-</li>
-</ul>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-<p><b>Rationale:</b></p>
-Addressed by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.html">N2661: A Foundation to Sleep On</a>.
-
-
-
-
-
-<hr>
-<h3><a name="790"></a>790. <tt>xor_combine::seed</tt> not specified</h3>
-<p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>xor_combine::seed(result_type)</tt> and <tt>seed(seed_seq&amp;)</tt> don't say what
-happens to each of the sub-engine seeds. (Should probably do the same
-to both, unlike TR1.)
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Overcome by the previous proposal. NAD mooted by resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-<hr>
-<h3><a name="791"></a>791. <tt>piecewise_constant_distribution::densities</tt> has wrong name</h3>
-<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>piecewise_constant_distribution::densities()</tt> should be <tt>probabilities()</tt>,
-just like <tt>discrete_distribution</tt>. (There's no real use for weights divided
-by areas.)
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Fermilab does not agree with this summary. As defined in the equation in
-26.4.8.5.2/4, the quantities are indeed probability densities not
-probabilities. Because we view this distribution as a parameterization
-of a *probability density function*, we prefer to work in terms of
-probability densities.
-</p>
-
-<p>
-We don't think this should be changed.
-</p>
-
-<p>
-If there is a technical argument about why the implementation dealing
-with these values can't be as efficient as one dealing with
-probabilities, we might reconsider. We don't care about this one member
-function being somewhat more or less efficient; we care about the size
-of the distribution object and the speed of the calls to generate
-variates.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change synopsis in 26.4.8.5.2 [rand.dist.samp.pconst]:
-</p>
-
-<blockquote><pre>template &lt;class RealType = double&gt;
-class piecewise_constant_distribution
-{
-public:
- ...
- vector&lt;double&gt; <del>densities</del> <ins>probabilities</ins>() const;
- ...
-};
-</pre></blockquote>
-
-<p>
-Change 26.4.8.5.2 [rand.dist.samp.pconst]/6:
-</p>
-
-<blockquote><pre>vector&lt;double&gt; <del>densities</del> <ins>probabilities</ins>() const;
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="795"></a>795. <tt>general_pdf_distribution</tt> should be dropped</h3>
-<p><b>Section:</b> 26.4.8.5.3 [rand.dist.samp.genpdf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.genpdf">issues</a> in [rand.dist.samp.genpdf].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#Dup">Dup</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a></p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>general_pdf_distribution</tt> should be dropped. (It's a research topic in
-adaptive numerical integration.)
-</p>
-
-<p><i>[
-Stephan Tolksdorf notes:
-]</i></p>
-
-
-<blockquote>
-This appears to be a duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="796"></a>796. <tt>ranlux48_base</tt> returns wrong value</h3>
-<p><b>Section:</b> 26.4.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The 10,000<sup>th</sup> value returned by <tt>ranlux48_base</tt> is supposed to be
-61839128582725. We get 192113843633948. (Note that the underlying
-generator was changed in Kona.)
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Submitter withdraws defect.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.4.5 [rand.predef]/p5:
-</p>
-
-<blockquote>
-<pre>typedef subtract_with_carry_engine&lt;uint_fast64_t, 48, 5, 12&gt;
- ranlux48_base;
-</pre>
-<blockquote>
-<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
-object of type <tt>ranlux48_base</tt> shall produce the value
-<del>61839128582725</del> <ins>192113843633948</ins>.
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="797"></a>797. <tt>ranlux48</tt> returns wrong value</h3>
-<p><b>Section:</b> 26.4.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The 10,000<sup>th</sup> value returned by <tt>ranlux48</tt> is supposed to be
-249142670248501. We get 88229545517833. (Note that this depends
-on <tt>ranlux48_base</tt>.)
-</p>
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Submitter withdraws defect.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.4.5 [rand.predef]/p6:
-</p>
-
-<blockquote>
-<pre>typedef discard_block_engine&lt;ranlux48_base, 389, 11&gt;
- ranlux48
-</pre>
-<blockquote>
-<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
-object of type <tt>ranlux48</tt> shall produce the value
-<del>249142670248501</del> <ins>88229545517833</ins>.
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="799"></a>799. [tr.rand.eng.mers] and [rand.eng.mers]</h3>
-<p><b>Section:</b> 26.4.3.2 [rand.eng.mers], TR1 5.1.4.2 [tr.rand.eng.mers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Stephan Tolksdorf <b>Date:</b> 2008-02-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.eng.mers">issues</a> in [rand.eng.mers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-TR1 5.1.4.2 [tr.rand.eng.mers](10) requires that <tt>operator==</tt> for the <tt>mersenne_twister</tt>
-returns <tt>true</tt> if and only if the states of two <tt>mersenne_twisters</tt>,
-consisting each of <tt>n</tt> integers between <tt>0</tt> and <tt>2<sup>w</sup> - 1</tt>, are completely
-equal. This is a contradiction with TR1 5.1.1 [tr.rand.req](3) because the given
-definition of the state also includes the lower <tt>r</tt> bits of <tt>x(i-n)</tt>, which
-will never be used to generate a random number. If two <tt>mersenne_twister</tt>s
-only differ in the lower bits of <tt>x(i-n)</tt> they will not compare equal,
-although they will produce an identical sequence of random numbers.
-</p>
-
-<p>
-26.4.3.2 [rand.eng.mers] in the latest C++ draft does not specify the behaviour
-of <tt>operator==</tt> but uses a similar definition of the state and, just like
-TR1 5.1.4.2 [tr.rand.eng.mers], requires the textual representation of a
-<tt>mersenne_twister_engine</tt> to consist of <tt>X<sub>i-n</sub></tt> to <tt>X<sub>i-1</sub></tt>, including the
-lower bits of <tt>X<sub>i-n</sub></tt>. This leads to two problems: First, the
-unsuspecting implementer is likely to erroneously compare the lower <tt>r</tt>
-bits of <tt>X<sub>i-n</sub></tt> in <tt>operator==</tt>. Second, if only the lower <tt>r</tt> bits differ,
-two <tt>mersenne_twister_engine</tt>s will compare equal (if correctly
-implemented) but have different textual representations, which
-conceptually is a bit ugly.
-</p>
-
-<p>
-I propose that a paragraph or footnote is added to 26.4.3.2 [rand.eng.mers] which
-clarifies that the lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> are not to be compared in
-<tt>operator==</tt> and <tt>operator!=</tt>. It would only be consequent if furthermore
-the specification for the textual respresentation was changed to
-<tt>X<sub>i-n</sub> bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)), X<sub>i-(n-1)</sub>, ..., X<sub>i-1</sub></tt> or
-something similar.
-</p>
-
-<p>
-These changes would likely have no practical effect, but would allow an
-implementation that does the right thing to be standard-conformant.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Fermi Lab has no objection to the proposed change. However it feels that
-more time is needed to check the details, which would suggest a change
-to REVIEW.
-</p>
-<p>
-Bill feels that this is NAD, not enough practical importance to abandon
-the simple definition of equality, and someone would have to do a lot
-more study to ensure that all cases are covered for a very small
-payback. The submitter admits that "These changes would likely have no
-practical effect,", and according to Plum's razor this means that it is
-not worth the effort!
-</p>
-<p>
-Revisted: Agree that the fact that there is no practical difference means that no change can be justified.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 26.4.3.2 [rand.eng.mers]:
-</p>
-
-<blockquote>
-<p>
-Insert at the end of para 2.:
-</p>
-
-<blockquote>
-[<i>Note:</i> The lower <tt>r</tt> bits of <tt>X<sub>i-n</sub></tt> do not influence
-the state transition and hence should not be compared when comparing two
-<tt>mersenne_twister_engine</tt> objects. <i>-- end note</i>]
-</blockquote>
-
-<p>
-In para 5. change:
-</p>
-
-<blockquote>
-The textual representation of <tt>x<sub>i</sub></tt> consists of the values of
-<tt>X<sub>i-n</sub> <ins>bitand ((2<sup>w</sup> - 1) - (2<sup>r</sup> - 1)), X<sub>i-(n-1)</sub></ins>,
-..., X<sub>i-1</sub></tt>, in that order.
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="802"></a>802. <tt>knuth_b</tt> returns wrong value</h3>
-<p><b>Section:</b> 26.4.5 [rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The 10,000<sup>th</sup> value returned by <tt>knuth_b</tt> is supposed to be
-1112339016. We get 2126698284.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.4.5 [rand.predef]/p8:
-</p>
-
-<blockquote>
-<pre>typedef shuffle_order_engine&lt;minstd_rand0, 256&gt;
- knuth_b;
-</pre>
-<blockquote>
-<i>Required behavior:</i> The 10000<sup>th</sup> consecutive invocation of a default-constructed
-object of type <tt>knuth_b</tt> shall produce the value
-<del>1112339016</del> <ins>2126698284</ins>.
-</blockquote>
-</blockquote>
-
-
-<p><i>[
-Bellevue: Submitter withdraws defect. "We got the wrong value for entirely the right reasons". NAD.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="826"></a>826. Equivalent of <tt>%'d</tt>, or rather, lack thereof?</h3>
-<p><b>Section:</b> 22.2.2.2 [locale.nm.put] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2008-04-07</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In the spirit of <tt>printf vs iostream</tt>...
-</p>
-
-<p>
-POSIX <tt>printf</tt> says that <tt>%'d</tt> should insert grouping characters (and the
-implication is that in the absence of <tt>'</tt> no grouping characters are
-inserted). The <tt>num_put</tt> facet, on the other hand, seems to always insert
-grouping characters. Can this be considered a defect worth fixing for
-C++0x? Maybe <tt>ios_base</tt> needs an additional flag?
-</p>
-
-<p><i>[
-Pablo Halpern:
-]</i></p>
-
-
-<blockquote>
-I'm not sure it constitutes a defect, but I would be in favor of adding
-another flag (and corresponding manipulator).
-</blockquote>
-
-<p><i>[
-Martin Sebor:
-]</i></p>
-
-
-<blockquote>
-I don't know if it qualifies as a defect but I agree that there
-should be an easy way to control whether the thousands separator
-should or shouldn't be inserted. A new flag would be in line with
-the current design of iostreams (like <tt>boolalpha</tt>, <tt>showpos</tt>, or
-<tt>showbase</tt>).
-</blockquote>
-
-<p><i>[
-Sophia Antipolis:
-]</i></p>
-
-
-<blockquote>
-This is not a part of C99. LWG suggests submitting a paper may be appropriate.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="831"></a>831. wrong type for not_eof()</h3>
-<p><b>Section:</b> 21.1.3 [char.traits.specializations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD%20Editorial">NAD Editorial</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 2008-04-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#char.traits.specializations">issues</a> in [char.traits.specializations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD%20Editorial">NAD Editorial</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
- In Table 56 (Traits requirements) the <tt>not_eof()</tt> member function
- is using an argument of type <i>e</i> which denotes an object of
- type <code>X::int_type</code>. However, the specializations in
- 21.1.3 [char.traits.specializations] all use <code>char_type</code>.
- This would effectively mean that the argument type actually can't
- represent EOF in the first place. I'm pretty sure that the type used
- to be <code>int_type</code> which is quite obviously the only sensible
- argument.
-</p>
-<p>
- This issue is close to being editorial. I suspect that the proposal
- changing this section to include the specializations for <code>char16_t</code>
- and <code>char32_t</code> accidentally used the wrong type.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
- In 21.1.3.1 [char.traits.specializations.char],
- 21.1.3.2 [char.traits.specializations.char16_t],
- 21.1.3.3 [char.traits.specializations.char32_t], and
- [char.traits.specializations.wchar_t] correct the
- argument type from <code>char_type</code> to <code>int_type</code>.
-</p>
-
-
-<p><b>Rationale:</b></p>
-Already fixed in WP.
-
-
-
-
-
-<hr>
-<h3><a name="840"></a>840. <tt>pair</tt> default template argument</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-05-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I have one issue with <tt>std::pair</tt>. Well, it might just be a very annoying
-historical accident, but why is there no default template argument for
-the second template argument? This is so annoying when the type in
-question is looong and hard to write (type deduction with <tt>auto</tt> won't
-help those cases where we use it as a return or argument type).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 20.2 [utility] to read:
-</p>
-
-<blockquote><pre>template &lt;class T1, class T2 <ins>= T1</ins>&gt; struct pair;
-</pre></blockquote>
-
-<p>
-Change 20.2.3 [pairs] to read:
-</p>
-
-<blockquote><pre>namespace std {
- template &lt;class T1, class T2 <ins>= T1</ins>&gt;
- struct pair {
- typedef T1 first_type;
- typedef T2 second_type;
- ...
-</pre></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<tt>std::pair</tt> is a heterogeneous container.
-
-
-
-
-
-</body></html> \ No newline at end of file
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-defects.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-defects.html
deleted file mode 100644
index 5951a9821..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/lwg-defects.html
+++ /dev/null
@@ -1,29778 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
-<html><head>
-<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
-
-
-<title>C++ Standard Library Defect Report List</title>
-<style type="text/css">
-p {text-align:justify}
-li {text-align:justify}
-ins {background-color:#A0FFA0}
-del {background-color:#FFA0A0}
-</style>
-</head><body>
-<table>
-<tbody><tr>
-<td align="left">Doc. no.</td>
-<td align="left">N2728=08-0238</td>
-</tr>
-<tr>
-<td align="left">Date:</td>
-<td align="left">2008-08-24</td>
-</tr>
-<tr>
-<td align="left">Project:</td>
-<td align="left">Programming Language C++</td>
-</tr>
-<tr>
-<td align="left">Reply to:</td>
-<td align="left">Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt;</td>
-</tr>
-</tbody></table>
-<h1>C++ Standard Library Defect Report List (Revision R59)</h1>
-
- <p>Reference ISO/IEC IS 14882:1998(E)</p>
- <p>Also see:</p>
- <ul>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
- <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
- </ul>
- <p>This document contains only library issues which have been closed
- by the Library Working Group (LWG) after being found to be defects
- in the standard. That is, issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>,
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a>. See the
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects. See the
- <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> for active issues and more information. The
- introductory material in that document also applies to this
- document.</p>
-
-<h2>Revision History</h2>
-<ul>
-<li>R59:
-2008-08-22 pre-San Francisco mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>192 open issues, up by 9.</li>
-<li>686 closed issues, up by 0.</li>
-<li>878 issues total, up by 9.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#870">870</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#871">871</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#872">872</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#873">873</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#874">874</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#875">875</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#876">876</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#877">877</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#878">878</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R58:
-2008-07-28 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>183 open issues, up by 12.</li>
-<li>686 closed issues, down by 4.</li>
-<li>869 issues total, up by 8.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#862">862</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#863">863</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#864">864</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#865">865</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#866">866</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#867">867</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#868">868</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#869">869</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
-<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
-<li>Changed the following issues from WP to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R57:
-2008-06-27 post-Sophia Antipolis mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>171 open issues, down by 20.</li>
-<li>690 closed issues, up by 43.</li>
-<li>861 issues total, up by 23.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#840">840</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#841">841</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#843">843</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#845">845</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#846">846</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#847">847</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#849">849</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#853">853</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#854">854</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#855">855</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#856">856</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#857">857</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#858">858</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#859">859</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#860">860</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#861">861</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#839">839</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#842">842</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#844">844</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#848">848</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#852">852</a>.</li>
-<li>Added the following Review issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#851">851</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>.</li>
-<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>.</li>
-<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>.</li>
-<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
-<li>Changed the following issues from Review to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396">396</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>.</li>
-<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
-<li>Changed the following issues from Ready to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R56:
-2008-05-16 pre-Sophia Antipolis mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>191 open issues, up by 24.</li>
-<li>647 closed issues, up by 1.</li>
-<li>838 issues total, up by 25.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#814">814</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#815">815</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#816">816</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#817">817</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#818">818</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#819">819</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#820">820</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#821">821</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#822">822</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#823">823</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#824">824</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#825">825</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#826">826</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#827">827</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#828">828</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#829">829</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#830">830</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#831">831</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#832">832</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#833">833</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#834">834</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#835">835</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#836">836</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#837">837</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#838">838</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R55:
-2008-03-14 post-Bellevue mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>167 open issues, down by 39.</li>
-<li>646 closed issues, up by 65.</li>
-<li>813 issues total, up by 26.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following Dup issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#795">795</a>.</li>
-<li>Added the following NAD issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#790">790</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#791">791</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#796">796</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#797">797</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#799">799</a>.</li>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#788">788</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#794">794</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#802">802</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#804">804</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#805">805</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#806">806</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#807">807</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#808">808</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#809">809</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#810">810</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#811">811</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#812">812</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#813">813</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#793">793</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#800">800</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#801">801</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a>.</li>
-<li>Added the following Ready issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#789">789</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#792">792</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#798">798</a>.</li>
-<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>.</li>
-<li>Changed the following issues from NAD Future to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>.</li>
-<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>.</li>
-<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
-<li>Changed the following issues from Review to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>.</li>
-<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#617">617</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>.</li>
-<li>Changed the following issues from Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>.</li>
-<li>Changed the following issues from Open to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#424">424</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>.</li>
-<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
-<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R54:
-2008-02-01 pre-Bellevue mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>206 open issues, up by 23.</li>
-<li>581 closed issues, up by 0.</li>
-<li>787 issues total, up by 23.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#765">765</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#766">766</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#767">767</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#768">768</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#769">769</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#770">770</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#771">771</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#772">772</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#773">773</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#774">774</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775">775</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#776">776</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778">778</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#779">779</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#780">780</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781">781</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#782">782</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#783">783</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#784">784</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#785">785</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#786">786</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#787">787</a>.</li>
-<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</li>
-<li>Changed the following issues from NAD Future to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>.</li>
-<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>.</li>
-<li>Changed the following issues from NAD Future to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>.</li>
-<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#527">527</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R53:
-2007-12-09 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>183 open issues, up by 11.</li>
-<li>581 closed issues, down by 1.</li>
-<li>764 issues total, up by 10.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#755">755</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#756">756</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#757">757</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#758">758</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#759">759</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#760">760</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761">761</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#762">762</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#763">763</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#764">764</a>.</li>
-<li>Changed the following issues from NAD to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>.</li>
-<li>Changed the following issues from Pending WP to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R52:
-2007-10-19 post-Kona mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>172 open issues, up by 4.</li>
-<li>582 closed issues, up by 27.</li>
-<li>754 issues total, up by 31.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#724">724</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#725">725</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#726">726</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#727">727</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#728">728</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#729">729</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#730">730</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#731">731</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#732">732</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#733">733</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#734">734</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#735">735</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#736">736</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#737">737</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#738">738</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#739">739</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#740">740</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#741">741</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#744">744</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#745">745</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#746">746</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#747">747</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#748">748</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#749">749</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#750">750</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#751">751</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#752">752</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#753">753</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#754">754</a>.</li>
-<li>Changed the following issues from NAD Future to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>.</li>
-<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#546">546</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550">550</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#564">564</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#565">565</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#573">573</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#585">585</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#588">588</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#393">393</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
-<li>Changed the following issues from New to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#607">607</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#608">608</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#561">561</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#562">562</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#563">563</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#581">581</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#595">595</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
-<li>Changed the following issues from New to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#574">574</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596">596</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#618">618</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>.</li>
-<li>Changed the following issues from New to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#552">552</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>.</li>
-<li>Changed the following issues from Open to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#401">401</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R51:
-2007-09-09 pre-Kona mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>168 open issues, up by 15.</li>
-<li>555 closed issues, up by 0.</li>
-<li>723 issues total, up by 15.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#709">709</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#710">710</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#711">711</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#712">712</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#713">713</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#714">714</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#715">715</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#716">716</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#717">717</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#718">718</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#719">719</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#720">720</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#721">721</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#722">722</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#723">723</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R50:
-2007-08-05 post-Toronto mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>153 open issues, down by 5.</li>
-<li>555 closed issues, up by 17.</li>
-<li>708 issues total, up by 12.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#697">697</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#698">698</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#699">699</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#700">700</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#701">701</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#702">702</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#703">703</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#704">704</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#705">705</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#706">706</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#707">707</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#708">708</a>.</li>
-<li>Changed the following issues from New to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#584">584</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>.</li>
-<li>Changed the following issues from Open to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.</li>
-<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>.</li>
-<li>Changed the following issues from Pending NAD Editorial to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#579">579</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>.</li>
-<li>Changed the following issues from Pending WP to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
-<li>Changed the following issues from Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#577">577</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>.</li>
-<li>Changed the following issues from Open to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>.</li>
-<li>Changed the following issues from Open to Review: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>.</li>
-<li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
-<li>Changed the following issues from DR to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453">453</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R49:
-2007-06-23 pre-Toronto mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>158 open issues, up by 13.</li>
-<li>538 closed issues, up by 7.</li>
-<li>696 issues total, up by 20.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#678">678</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#679">679</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#680">680</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#681">681</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#682">682</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#684">684</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#685">685</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#686">686</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#687">687</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#688">688</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#689">689</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#690">690</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#691">691</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#692">692</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693">693</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#694">694</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695">695</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#696">696</a>.</li>
-<li>Added the following Pending NAD Editorial issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#683">683</a>.</li>
-<li>Changed the following issues from New to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#587">587</a>.</li>
-<li>Changed the following issues from Open to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R48:
-2007-05-06 post-Oxford mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>145 open issues, down by 33.</li>
-<li>531 closed issues, up by 53.</li>
-<li>676 issues total, up by 20.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#657">657</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#658">658</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#659">659</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660">660</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#661">661</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#662">662</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#663">663</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#664">664</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#665">665</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#666">666</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#667">667</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#668">668</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#669">669</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#670">670</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#671">671</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#672">672</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#673">673</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#675">675</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#676">676</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Dup: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>.</li>
-<li>Changed the following issues from Tentatively Ready to NAD: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
-<li>Changed the following issues from NAD to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#357">357</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#368">368</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a>.</li>
-<li>Changed the following issues from Tentatively Ready to NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>.</li>
-<li>Changed the following issues from NAD_Future to NAD Future: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#105">105</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#149">149</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#188">188</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#219">219</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#353">353</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#388">388</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>.</li>
-<li>Changed the following issues from New to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Pending NAD Editorial: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>.</li>
-<li>Changed the following issues from Tentatively Ready to Pending WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>.</li>
-<li>Changed the following issues from New to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>.</li>
-<li>Changed the following issues from Review to Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a>.</li>
-<li>Changed the following issues from Ready to TRDec: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#599">599</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#600">600</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#601">601</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#602">602</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a>.</li>
-<li>Changed the following issues from Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>.</li>
-<li>Changed the following issues from Tentatively Ready to WP: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R47:
-2007-03-09 pre-Oxford mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>178 open issues, up by 37.</li>
-<li>478 closed issues, up by 0.</li>
-<li>656 issues total, up by 37.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added the following New issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#620">620</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#621">621</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#622">622</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#623">623</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#624">624</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#627">627</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#628">628</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#629">629</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#630">630</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#631">631</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#632">632</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#633">633</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#634">634</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#635">635</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#636">636</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#637">637</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#638">638</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#639">639</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#640">640</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#641">641</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#642">642</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#643">643</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#644">644</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#645">645</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#646">646</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#647">647</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#648">648</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#649">649</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#650">650</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#651">651</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#652">652</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#653">653</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#654">654</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#655">655</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#656">656</a>.</li>
-<li>Added the following Open issues: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#625">625</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#626">626</a>.</li>
-<li>Changed the following issues from New to Open: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#570">570</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#590">590</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#612">612</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#614">614</a>.</li>
-<li>Changed the following issues from New to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#547">547</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#553">553</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#560">560</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#571">571</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#576">576</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#578">578</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586">586</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#589">589</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#591">591</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#594">594</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#611">611</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#613">613</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#615">615</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#616">616</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-<li>Changed the following issues from Open to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#201">201</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#206">206</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#258">258</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#385">385</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#416">416</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#422">422</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456">456</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#466">466</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#470">470</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#471">471</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#482">482</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>.</li>
-<li>Changed the following issues from Review to Tentatively Ready: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R46:
-2007-01-12 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>141 open issues, up by 11.</li>
-<li>478 closed issues, down by 1.</li>
-<li>619 issues total, up by 10.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#610">610</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#619">619</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R45:
-2006-11-03 post-Portland mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>130 open issues, up by 0.</li>
-<li>479 closed issues, up by 17.</li>
-<li>609 issues total, up by 17.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a> to WP.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a> to NAD.</li>
-<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#605">605</a> to Ready.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#604">604</a> to Review.</li>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#609">609</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R44:
-2006-09-08 pre-Portland mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>130 open issues, up by 6.</li>
-<li>462 closed issues, down by 1.</li>
-<li>592 issues total, up by 5.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#592">592</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R43:
-2006-06-23 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>124 open issues, up by 14.</li>
-<li>463 closed issues, down by 1.</li>
-<li>587 issues total, up by 13.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#575">575</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.</li>
-<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.</li>
-</ul></li>
-</ul>
-</li>
-<li>R42:
-2006-04-21 post-Berlin mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>110 open issues, down by 16.</li>
-<li>464 closed issues, up by 24.</li>
-<li>574 issues total, up by 8.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#572">572</a>.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#548">548</a> to Open.</li>
-<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready.</li>
-<li>Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP.</li>
-<li>Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#534">534</a> to Review.</li>
-</ul></li>
-</ul>
-</li>
-<li>R41:
-2006-02-24 pre-Berlin mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>126 open issues, up by 31.</li>
-<li>440 closed issues, up by 0.</li>
-<li>566 issues total, up by 31.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#566">566</a>.</li>
-<li>Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.</li>
-<li>Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R40:
-2005-12-16 mid-term mailing.
-<ul>
-<li><b>Summary:</b><ul>
-<li>95 open issues.</li>
-<li>440 closed issues.</li>
-<li>535 issues total.</li>
-</ul></li>
-<li><b>Details:</b><ul>
-<li>Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>.</li>
-</ul></li>
-</ul>
-</li>
-<li>R39:
-2005-10-14 post-Mont Tremblant mailing.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#528">528</a>.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready.
-Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
-Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518">518</a> from New to Review.
-</li>
-<li>R38:
-2005-07-03 pre-Mont Tremblant mailing.
-Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
-</li>
-<li>R37:
-2005-06 mid-term mailing.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>.
-</li>
-<li>R36:
-2005-04 post-Lillehammer mailing. All issues in "ready" status except
-for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues
-previously in "DR" status were moved to "WP".
-</li>
-<li>R35:
-2005-03 pre-Lillehammer mailing.
-</li>
-<li>R34:
-2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
-</li>
-<li>R33:
-2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
-</li>
-<li>R32:
-2004-09 pre-Redmond mailing: reflects new proposed resolutions and
-new issues received after the 2004-07 mailing. Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
-</li>
-<li>R31:
-2004-07 mid-term mailing: reflects new proposed resolutions and
-new issues received after the post-Sydney mailing. Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
-</li>
-<li>R30:
-Post-Sydney mailing: reflects decisions made at the Sydney meeting.
-Voted all "Ready" issues from R29 into the working paper.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#462">462</a>.
-</li>
-<li>R29:
-Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
-</li>
-<li>R28:
-Post-Kona mailing: reflects decisions made at the Kona meeting.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>.
-</li>
-<li>R27:
-Pre-Kona mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
-</li>
-<li>R26:
-Post-Oxford mailing: reflects decisions made at the Oxford meeting.
-All issues in Ready status were voted into DR status. All issues in
-DR status were voted into WP status.
-</li>
-<li>R25:
-Pre-Oxford mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>.
-</li>
-<li>R24:
-Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
-meeting. All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
-moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
-at the meeting.) Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
-concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
-</li>
-<li>R23:
-Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#382">382</a>.
-Moved issues in the TC to TC status.
-</li>
-<li>R22:
-Post-Curaao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
-</li>
-<li>R21:
-Pre-Curaao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>.
-</li>
-<li>R20:
-Post-Redmond mailing; reflects actions taken in Redmond. Added
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a> were added since Redmond, hence
-not discussed at the meeting.
-
-All Ready issues were moved to DR status, with the exception of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
-
-Noteworthy issues discussed at Redmond include
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
-</li>
-<li>R19:
-Pre-Redmond mailing. Added new issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>.
-</li>
-<li>R18:
-Post-Copenhagen mailing; reflects actions taken in Copenhagen.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed
-new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>.
-
-Changed status of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
-to DR.
-
-Changed status of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>
-to Ready.
-
-Closed issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
-as NAD.
-
-</li>
-<li>R17:
-Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
-resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
-Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>.
-</li>
-<li>R16:
-post-Toronto mailing; reflects actions taken in Toronto. Added new
-issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>. Changed status of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>. Reopened
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
-appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
-the bug in enough places.
-</li>
-<li>R15:
-pre-Toronto mailing. Added issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>. Some small HTML formatting
-changes so that we pass Weblint tests.
-</li>
-<li>R14:
-post-Tokyo II mailing; reflects committee actions taken in
-Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
-</li>
-<li>R13:
-pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.
-</li>
-<li>R12:
-pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
-of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
-</li>
-<li>R11:
-post-Kona mailing: Updated to reflect LWG and full committee actions
-in Kona (99-0048/N1224). Note changed resolution of issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a>
-to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
-"closed" documents. Changed the proposed resolution of issue
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
-of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
-</li>
-<li>R10:
-pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#190">190</a> to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
-</li>
-<li>R9:
-pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
-"closed" documents. (99-0030/N1206, 25 Aug 99)
-</li>
-<li>R8:
-post-Dublin mailing. Updated to reflect LWG and full committee actions
-in Dublin. (99-0016/N1193, 21 Apr 99)
-</li>
-<li>R7:
-pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
-</li>
-<li>R6:
-pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#128">128</a>,
-and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
-</li>
-<li>R5:
-update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>. Format revisions to prepare
-for making list public. (30 Dec 98)
-</li>
-<li>R4:
-post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
-issues corrected. (22 Oct 98)
-</li>
-<li>R3:
-post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>
-added, many issues updated to reflect LWG consensus (12 Oct 98)
-</li>
-<li>R2:
-pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added,
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
-</li>
-<li>R1:
-Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code
-format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
-</li>
-</ul>
-
-<h2>Defect Reports</h2>
-<hr>
-<h3><a name="1"></a>1. C library linkage editing oversight</h3>
-<p><b>Section:</b> 17.4.2.2 [using.linkage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 1997-11-16</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The change specified in the proposed resolution below did not make
-it into the Standard. This change was accepted in principle at the
-London meeting, and the exact wording below was accepted at the
-Morristown meeting.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 17.4.2.2 [using.linkage] paragraph 2
-from:</p>
-
-<blockquote>
- <p>It is unspecified whether a name from the Standard C library
- declared with external linkage has either extern "C" or
- extern "C++" linkage.</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- <p>Whether a name from the Standard C library declared with external
- linkage has extern "C" or extern "C++" linkage
- is implementation defined. It is recommended that an implementation
- use extern "C++" linkage for this purpose.</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="3"></a>3. Atexit registration during atexit() call is not described</h3>
-<p><b>Section:</b> 18.4 [support.start.term] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1997-12-12</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>We appear not to have covered all the possibilities of
- exit processing with respect to
-atexit registration. <br>
-<br>
-Example 1: (C and C++)</p>
-
-<pre> #include &lt;stdlib.h&gt;
- void f1() { }
- void f2() { atexit(f1); }
-
- int main()
- {
- atexit(f2); // the only use of f2
- return 0; // for C compatibility
- }</pre>
-
-<p>At program exit, f2 gets called due to its registration in
-main. Running f2 causes f1 to be newly registered during the exit
-processing. Is this a valid program? If so, what are its
-semantics?</p>
-
-<p>
-Interestingly, neither the C standard, nor the C++ draft standard nor
-the forthcoming C9X Committee Draft says directly whether you can
-register a function with atexit during exit processing.</p>
-
-<p>
-All 3 standards say that functions are run in reverse order of their
-registration. Since f1 is registered last, it ought to be run first,
-but by the time it is registered, it is too late to be first.</p>
-
-<p>If the program is valid, the standards are self-contradictory about
-its semantics.</p>
-
-<p>Example 2: (C++ only)</p>
-
-<pre>
- void F() { static T t; } // type T has a destructor
-
- int main()
- {
- atexit(F); // the only use of F
- }
-</pre>
-
-<p>Function F registered with atexit has a local static variable t,
-and F is called for the first time during exit processing. A local
-static object is initialized the first time control flow passes
-through its definition, and all static objects are destroyed during
-exit processing. Is the code valid? If so, what are its semantics?</p>
-
-<p>
-Section 18.3 "Start and termination" says that if a function
-F is registered with atexit before a static object t is initialized, F
-will not be called until after t's destructor completes.</p>
-
-<p>
-In example 2, function F is registered with atexit before its local
-static object O could possibly be initialized. On that basis, it must
-not be called by exit processing until after O's destructor
-completes. But the destructor cannot be run until after F is called,
-since otherwise the object could not be constructed in the first
-place.</p>
-
-<p>If the program is valid, the standard is self-contradictory about
-its semantics.</p>
-
-<p>I plan to submit Example 1 as a public comment on the C9X CD, with
-a recommendation that the results be undefined. (Alternative: make it
-unspecified. I don't think it is worthwhile to specify the case where
-f1 itself registers additional functions, each of which registers
-still more functions.)</p>
-
-<p>I think we should resolve the situation in the whatever way the C
-committee decides. </p>
-
-<p>For Example 2, I recommend we declare the results undefined.</p>
-
-<p><i>[See reflector message lib-6500 for further discussion.]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change section 18.3/8 from:</p>
-<blockquote><p>
- First, objects with static storage duration are destroyed and
- functions registered by calling atexit are called. Objects with
- static storage duration are destroyed in the reverse order of the
- completion of their constructor. (Automatic objects are not
- destroyed as a result of calling exit().) Functions registered with
- atexit are called in the reverse order of their registration. A
- function registered with atexit before an object obj1 of static
- storage duration is initialized will not be called until obj1's
- destruction has completed. A function registered with atexit after
- an object obj2 of static storage duration is initialized will be
- called before obj2's destruction starts.
-</p></blockquote>
-<p>to:</p>
-<blockquote><p>
- First, objects with static storage duration are destroyed and
- functions registered by calling atexit are called. Non-local objects
- with static storage duration are destroyed in the reverse order of
- the completion of their constructor. (Automatic objects are not
- destroyed as a result of calling exit().) Functions registered with
- atexit are called in the reverse order of their registration, except
- that a function is called after any previously registered functions
- that had already been called at the time it was registered. A
- function registered with atexit before a non-local object obj1 of
- static storage duration is initialized will not be called until
- obj1's destruction has completed. A function registered with atexit
- after a non-local object obj2 of static storage duration is
- initialized will be called before obj2's destruction starts. A local
- static object obj3 is destroyed at the same time it would be if a
- function calling the obj3 destructor were registered with atexit at
- the completion of the obj3 constructor.
-</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
-supporting to the proposed resolution.</p>
-
-
-
-
-
-<hr>
-<h3><a name="5"></a>5. String::compare specification questionable</h3>
-<p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Jack Reeves <b>Date:</b> 1997-12-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#87">87</a></p>
-<p><b>Discussion:</b></p>
-<p>At the very end of the basic_string class definition is the signature: int
-compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
-following text this is defined as: returns
-basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
-basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>
-
-<p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
-= Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
-throws length_error if n == npos, it appears the compare() signature above should always
-throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
-null terminated character array. </p>
-
-<p>This appears to be a typo since the obvious intent is to allow either the call above or
-something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
-
-<p>This would imply that what was really intended was two signatures int compare(size_type
-pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
-charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace the compare signature in 21.3 [basic.string]
-(at the very end of the basic_string synopsis) which reads:</p>
-
-<blockquote>
- <p><tt>int compare(size_type pos1, size_type n1,<br>
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
- size_type n2 = npos) const;</tt></p>
-</blockquote>
-
-<p>with:</p>
-
-<blockquote>
- <p><tt>int compare(size_type pos1, size_type n1,<br>
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
- int compare(size_type pos1, size_type n1,<br>
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
- size_type n2) const;</tt></p>
-</blockquote>
-
-<p>Replace the portion of 21.3.6.8 [string::swap]
-paragraphs 5 and 6 which read:</p>
-
-<blockquote>
- <p><tt>int compare(size_type pos, size_type n1,<br>
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
- = npos) const;<br>
- </tt>Returns:<tt><br>
- basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
-</blockquote>
-
-<p>with:</p>
-
-<blockquote>
- <p><tt>int compare(size_type pos, size_type n1,<br>
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
- </tt>Returns:<tt><br>
- basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
- <br>
- int compare(size_type pos, size_type n1,<br>
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
- size_type n2) const;<br>
- </tt>Returns:<tt><br>
- basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
-</blockquote>
-
-<p>Editors please note that in addition to splitting the signature, the third argument
-becomes const, matching the existing synopsis.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>While the LWG dislikes adding signatures, this is a clear defect in
-the Standard which must be fixed.&nbsp; The same problem was also
-identified in issues 7 (item 5) and 87.</p>
-
-
-
-
-
-<hr>
-<h3><a name="7"></a>7. String clause minor problems</h3>
-<p><b>Section:</b> 21 [strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#strings">issues</a> in [strings].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>(1) In 21.3.6.4 [string::insert], the description of template
-&lt;class InputIterator&gt; insert(iterator, InputIterator,
-InputIterator) makes no sense. It refers to a member function that
-doesn't exist. It also talks about the return value of a void
-function. </p>
-
-<p>(2) Several versions of basic_string::replace don't appear in the
-class synopsis. </p>
-
-<p>(3) basic_string::push_back appears in the synopsis, but is never
-described elsewhere. In the synopsis its argument is const charT,
-which doesn't makes much sense; it should probably be charT, or
-possible const charT&amp;. </p>
-
-<p>(4) basic_string::pop_back is missing. </p>
-
-<p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
-= npos) make no sense. First, it's const charT* in the synopsis and
-charT* in the description. Second, given what it says in RETURNS,
-leaving out the final argument will always result in an exception
-getting thrown. This is paragraphs 5 and 6 of
-21.3.6.8 [string::swap]</p>
-
-<p>(6) In table 37, in section 21.1.1 [char.traits.require],
-there's a note for X::move(s, p, n). It says "Copies correctly
-even where p is in [s, s+n)". This is correct as far as it goes,
-but it doesn't go far enough; it should also guarantee that the copy
-is correct even where s in in [p, p+n). These are two orthogonal
-guarantees, and neither one follows from the other. Both guarantees
-are necessary if X::move is supposed to have the same sort of
-semantics as memmove (which was clearly the intent), and both
-guarantees are necessary if X::move is actually supposed to be
-useful. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
-<br>
-&nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
-<br>
-ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
-the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
-<br>
-ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
-[lib.basic.string]) from:</p>
-
-<p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
-<br>
-to<br>
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
-<br>
-Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
-<br>
-&nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
-&nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
-<br>
-ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
-<br>
-ITEM 5: Duplicate; see issue 5 (and 87).<br>
-<br>
-ITEM 6: In table 37, Replace:<br>
-<br>
-&nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
-<br>
-with:<br>
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
-s+n) overlap."</p>
-
-
-
-
-
-<hr>
-<h3><a name="8"></a>8. Locale::global lacks guarantee</h3>
-<p><b>Section:</b> 22.1.1.5 [locale.statics] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1997-12-24</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>It appears there's an important guarantee missing from clause
-22. We're told that invoking locale::global(L) sets the C locale if L
-has a name. However, we're not told whether or not invoking
-setlocale(s) sets the global C++ locale. </p>
-
-<p>The intent, I think, is that it should not, but I can't find any
-such words anywhere. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add a sentence at the end of 22.1.1.5 [locale.statics],
-paragraph 2:&nbsp; </p>
-
-<blockquote>
- <p>No library function other than <tt>locale::global()</tt> shall affect
- the value returned by <tt>locale()</tt>. </p>
-
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="9"></a>9. Operator new(0) calls should not yield the same pointer</h3>
-<p><b>Section:</b> 18.5.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-01-04</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
-section 3.7.3.1 of CD2 seems to allow for the possibility that all
-calls to operator new(0) yield the same pointer, an implementation
-technique specifically prohibited by ARM 5.3.3.Was this prohibition
-really lifted? Does the FDIS agree with CD2 in the regard? [Issues
-list maintainer's note: the IS is the same.]</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the last paragraph of 3.7.3 from:</p>
-<blockquote>
- <p>Any allocation and/or deallocation functions defined in a C++ program shall
- conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>Any allocation and/or deallocation functions defined in a C++ program,
- including the default versions in the library, shall conform to the semantics
- specified in 3.7.3.1 and 3.7.3.2.</p>
-</blockquote>
-<p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
-<blockquote>
- <p>If the size of the space requested is zero, the value returned shall not be
- a null pointer value (4.10).</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>Even if the size of the space requested is zero, the request can fail. If
- the request succeeds, the value returned shall be a non-null pointer value
- (4.10) p0 different from any previously returned value p1, unless that value
- p1 was since passed to an operator delete.</p>
-</blockquote>
-<p>5.3.4/7 currently reads:</p>
-<blockquote>
- <p>When the value of the expression in a direct-new-declarator is zero, the
- allocation function is called to allocate an array with no elements. The
- pointer returned by the new-expression is non-null. [Note: If the library
- allocation function is called, the pointer returned is distinct from the
- pointer to any other object.]</p>
-</blockquote>
-<p>Retain the first sentence, and delete the remainder.</p>
-<p>18.5.1 currently has no text. Add the following:</p>
-<blockquote>
- <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
- library versions of operator new and operator delete.</p>
-</blockquote>
-<p>To 18.5.1.3, add the following text:</p>
-<blockquote>
- <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
- operator new and operator delete.</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
-supporting to the proposed resolution.</p>
-
-
-
-
-
-<hr>
-<h3><a name="11"></a>11. Bitset minor problems</h3>
-<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-01-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
-not documented in 23.3.5.2. </p>
-
-<p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
-reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
-on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
-
-<p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
-trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
-go in the Effects clause.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>ITEMS 1 AND 2:<br>
-<br>
-In the bitset synopsis (23.3.5 [template.bitset]),
-replace the member function <br>
-<br>
-<tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
-</tt><br>
-with the two member functions<br>
-<br>
-<tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
-&nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
-</tt><br>
-Add the following text at the end of 23.3.5.2 [bitset.members],
-immediately after paragraph 45:</p>
-
-<blockquote>
- <p><tt>bool operator[](size_t pos) const;</tt><br>
- Requires: pos is valid<br>
- Throws: nothing<br>
- Returns: <tt>test(pos)</tt><br>
- <br>
- <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
- Requires: pos is valid<br>
- Throws: nothing<br>
- Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
- == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
- val);</tt></p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes Item 3 is not a defect. "Formatted
-input" implies the desired semantics. See 27.6.1.2 [istream.formatted].
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="13"></a>13. Eos refuses to die</h3>
-<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> William M. Miller <b>Date:</b> 1998-03-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 27.6.1.2.3, there is a reference to "eos", which is
-the only one in the whole draft (at least using Acrobat search), so
-it's undefined. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.2.3 [istream::extractors], replace "eos" with
-"charT()"</p>
-
-
-
-
-
-<hr>
-<h3><a name="14"></a>14. Locale::combine should be const</h3>
-<p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>locale::combine is the only member function of locale (other than constructors and
-destructor) that is not const. There is no reason for it not to be const, and good reasons
-why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
-paragraph 6: "An instance of a locale is immutable." </p>
-
-<p>History: this member function originally was a constructor. it happened that the
-interface it specified had no corresponding language syntax, so it was changed to a member
-function. As constructors are never const, there was no "const" in the interface
-which was transformed into member "combine". It should have been added at that
-time, but the omission was not noticed. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1 [locale] and also in 22.1.1.3 [locale.members], add
-"const" to the declaration of member combine: </p>
-<blockquote>
- <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="15"></a>15. Locale::name requirement inconsistent</h3>
-<p><b>Section:</b> 22.1.1.3 [locale.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.members">issues</a> in [locale.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>locale::name() is described as returning a string that can be passed to a locale
-constructor, but there is no matching constructor. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1.3 [locale.members], paragraph 5, replace
-"<tt>locale(name())</tt>" with
-"<tt>locale(name().c_str())</tt>".
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="16"></a>16. Bad ctype_byname&lt;char&gt; decl</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
-edited in properly. Instead, the member do_widen appears four times, with wrong argument
-lists. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>The correct declarations for the overloaded members
-<tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
-from 22.2.1.3 [facet.ctype.special].</p>
-
-
-
-
-
-<hr>
-<h3><a name="17"></a>17. Bad bool parsing</h3>
-<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>This section describes the process of parsing a text boolean value from the input
-stream. It does not say it recognizes either of the sequences "true" or
-"false" and returns the corresponding bool value; instead, it says it recognizes
-only one of those sequences, and chooses which according to the received value of a
-reference argument intended for returning the result, and reports an error if the other
-sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
-facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
-flag wrongly; it doesn't define the value "loc"; and finally, it computes
-wrongly whether to use numeric or "alpha" parsing.<br>
-<br>
-I believe the correct algorithm is "as if": </p>
-
-<pre> // in, err, val, and str are arguments.
- err = 0;
- const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
- const string_type t = np.truename(), f = np.falsename();
- bool tm = true, fm = true;
- size_t pos = 0;
- while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
- if (in == end) { err = str.eofbit; }
- bool matched = false;
- if (tm &amp;&amp; pos &lt; t.size()) {
- if (!err &amp;&amp; t[pos] == *in) matched = true;
- else tm = false;
- }
- if (fm &amp;&amp; pos &lt; f.size()) {
- if (!err &amp;&amp; f[pos] == *in) matched = true;
- else fm = false;
- }
- if (matched) { ++in; ++pos; }
- if (pos &gt; t.size()) tm = false;
- if (pos &gt; f.size()) fm = false;
- }
- if (tm == fm || pos == 0) { err |= str.failbit; }
- else { val = tm; }
- return in;</pre>
-
-<p>Notice this works reasonably when the candidate strings are both empty, or equal, or
-when one is a substring of the other. The proposed text below captures the logic of the
-code above.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.1.2 [facet.num.get.virtuals], in the first line of paragraph 14,
-change "&amp;&amp;" to "&amp;".</p>
-
-<p>Then, replace paragraphs 15 and 16 as follows:</p>
-
-<blockquote>
-
- <p>Otherwise target sequences are determined "as if" by
- calling the members <tt>falsename()</tt> and
- <tt>truename()</tt> of the facet obtained by
- <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.
- Successive characters in the range <tt>[in,end)</tt> (see
- [lib.sequence.reqmts]) are obtained and matched against
- corresponding positions in the target sequences only as necessary to
- identify a unique match. The input iterator <tt>in</tt> is
- compared to <tt>end</tt> only when necessary to obtain a
- character. If and only if a target sequence is uniquely matched,
- <tt>val</tt> is set to the corresponding value.</p>
-
-</blockquote>
-
-<blockquote>
- <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
- successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
- <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
- <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
- <tt>(str.failbit|str.eofbit)</tt>if
- the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
- <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
- <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
- <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
- <tt>true</tt>:"1"
- and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
- and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
- <tt>err==str.failbit</tt>. --end example]</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="18"></a>18. Get(...bool&amp;) omitted</h3>
-<p><b>Section:</b> 22.2.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.members">issues</a> in [facet.num.get.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
-that parses bool values was omitted from the list of definitions of non-virtual
-members, though it is listed in the class definition and the corresponding
-virtual is listed everywhere appropriate. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add at the beginning of 22.2.2.1.1 [facet.num.get.members]
-another get member for bool&amp;, copied from the entry in
-22.2.2.1 [locale.num.get].</p>
-
-
-
-
-
-<hr>
-<h3><a name="19"></a>19. "Noconv" definition too vague</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#10">10</a></p>
-<p><b>Discussion:</b></p>
-<p>
-In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
-specified to return noconv if "no conversion is
-needed". This definition is too vague, and does not say
-normatively what is done with the buffers.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the entry for noconv in the table under paragraph 4 in section
-22.2.1.4.2 [locale.codecvt.virtuals] to read:
-</p>
-<blockquote>
- <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
- and input sequence is identical to converted sequence.</p>
-</blockquote>
-<p>Change the Note in paragraph 2 to normative text as follows:</p>
-<blockquote>
- <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
- same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
- <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
- unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="20"></a>20. Thousands_sep returns wrong type</h3>
-<p><b>Section:</b> 22.2.3.1.2 [facet.numpunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
-definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
-that it returns a value of type char_type. Here it is erroneously
-described as returning a "string_type". </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.3.1.2 [facet.numpunct.virtuals], above paragraph 2, change
-"string_type" to "char_type". </p>
-
-
-
-
-
-<hr>
-<h3><a name="21"></a>21. Codecvt_byname&lt;&gt; instantiations</h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In the second table in the section, captioned "Required
-instantiations", the instantiations for codecvt_byname&lt;&gt;
-have been omitted. These are necessary to allow users to construct a
-locale by name from facets. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add in 22.1.1.1.1 [locale.category] to the table captioned
-"Required instantiations", in the category "ctype"
-the lines </p>
-
-<blockquote>
- <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
-codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="22"></a>22. Member open vs. flags</h3>
-<p><b>Section:</b> 27.8.1.9 [ifstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
-responds to or changes flags in the error status for the stream. A strict reading
-indicates that it ignores the bits and does not change them, which confuses users who do
-not expect eofbit and failbit to remain set after a successful open. There are three
-reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
-and eofbit on call to open(). </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.8.1.9 [ifstream.members] paragraph 3, <i>and</i> in 27.8.1.13 [ofstream.members] paragraph 3, under open() effects, add a footnote:
-</p>
-
-<blockquote>
- <p>A successful open does not change the error state.</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>This may seem surprising to some users, but it's just an instance
-of a general rule: error flags are never cleared by the
-implementation. The only way error flags are are ever cleared is if
-the user explicitly clears them by hand.</p>
-
-<p>The LWG believed that preserving this general rule was
-important enough so that an exception shouldn't be made just for this
-one case. The resolution of this issue clarifies what the LWG
-believes to have been the original intent.</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="24"></a>24. "do_convert" doesn't exist</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#72">72</a></p>
-<p><b>Discussion:</b></p>
-<p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
-symbol "do_convert" which is not defined in the
-standard. This is a leftover from an edit, and should be "do_in
-and do_out". </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.4 [locale.codecvt], paragraph 3, change
-"do_convert" to "do_in or do_out". Also, in 22.2.1.4.2 [locale.codecvt.virtuals], change "do_convert()" to "do_in
-or do_out". </p>
-
-
-
-
-
-<hr>
-<h3><a name="25"></a>25. String operator&lt;&lt; uses width() value wrong</h3>
-<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#67">67</a></p>
-<p><b>Discussion:</b></p>
-<p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
-the smaller of os.width() and str.size(), to pad "as described in stage 3"
-elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 21.3.8.9 [string.io] paragraph 4 from:<br>
-<br>
-&nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
-..."<br>
-<br>
-to: <br>
-<br>
-&nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
-..."</p>
-
-
-
-
-
-<hr>
-<h3><a name="26"></a>26. Bad sentry example</h3>
-<p><b>Section:</b> 27.6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In paragraph 6, the code in the example: </p>
-
-<pre> template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
- basic_istream&lt;charT,traits&gt;::sentry(
- basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
- ...
- int_type c;
- typedef ctype&lt;charT&gt; ctype_type;
- const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
- while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
- if (ctype.is(ctype.space,c)==0) {
- is.rdbuf()-&gt;sputbackc (c);
- break;
- }
- }
- ...
- }</pre>
-
-<p>fails to demonstrate correct use of the facilities described. In
-particular, it fails to use traits operators, and specifies incorrect
-semantics. (E.g. it specifies skipping over the first character in the
-sequence without examining it.) </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Remove the example above from 27.6.1.1.3 [istream::sentry]
-paragraph 6.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The originally proposed replacement code for the example was not
-correct. The LWG tried in Kona and again in Tokyo to correct it
-without success. In Tokyo, an implementor reported that actual working
-code ran over one page in length and was quite complicated. The LWG
-decided that it would be counter-productive to include such a lengthy
-example, which might well still contain errors.</p>
-
-
-
-
-
-<hr>
-<h3><a name="27"></a>27. String::erase(range) yields wrong iterator</h3>
-<p><b>Section:</b> 21.3.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::erase">issues</a> in [string::erase].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The string::erase(iterator first, iterator last) is specified to return an element one
-place beyond the next element after the last one erased. E.g. for the string
-"abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
-while 'd' has not been erased. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 21.3.6.5 [string::erase], paragraph 10, change: </p>
-
-<blockquote>
- <p>Returns: an iterator which points to the element immediately following _last_ prior to
- the element being erased. </p>
-</blockquote>
-
-<p>to read </p>
-
-<blockquote>
- <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
- other elements being erased. </p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="28"></a>28. Ctype&lt;char&gt;is ambiguous</h3>
-<p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#236">236</a></p>
-<p><b>Discussion:</b></p>
-<p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
-something very different from what was intended. Paragraph 4 says </p>
-
-<blockquote>
- <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
- table()[(unsigned char)*p]. </p>
-</blockquote>
-
-<p>This is intended to copy the value indexed from table()[] into the place identified in
-vec[]. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 22.2.1.3.2 [facet.ctype.char.members], paragraph 4, to read </p>
-
-<blockquote>
- <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
- the value table()[(unsigned char)*p]. </p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="29"></a>29. Ios_base::init doesn't exist</h3>
-<p><b>Section:</b> 27.3.1 [narrow.stream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#narrow.stream.objects">issues</a> in [narrow.stream.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Sections 27.3.1 [narrow.stream.objects] and 27.3.2 [wide.stream.objects] mention
-a function ios_base::init, which is not defined. Probably they mean
-basic_ios&lt;&gt;::init, defined in 27.4.4.1 [basic.ios.cons],
-paragraph 3. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>[R12: modified to include paragraph 5.]</p>
-
-<p>In 27.3.1 [narrow.stream.objects] paragraph 2 and 5, change </p>
-
-<blockquote>
- <p>ios_base::init </p>
-</blockquote>
-
-<p>to </p>
-
-<blockquote>
- <p>basic_ios&lt;char&gt;::init </p>
-</blockquote>
-
-<p>Also, make a similar change in 27.3.2 [wide.stream.objects] except it
-should read </p>
-
-<blockquote>
- <p>basic_ios&lt;wchar_t&gt;::init </p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="30"></a>30. Wrong header for LC_*</h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
-where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1.1.1 [locale.category], paragraph 2, change
-"&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>
-
-
-
-
-
-<hr>
-<h3><a name="31"></a>31. Immutable locale values</h3>
-<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#378">378</a></p>
-<p><b>Discussion:</b></p>
-<p>Paragraph 6, says "An instance of <tt>locale</tt> is
-<i>immutable</i>; once a facet reference is obtained from it,
-...". This has caused some confusion, because locale variables
-are manifestly assignable. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1 [locale] replace paragraph 6</p>
-
-<blockquote>
- <p>An instance of <tt>locale</tt> is immutable; once a facet
- reference is obtained from it, that reference remains usable as long
- as the locale value itself exists.</p>
-</blockquote>
-
-<p>with</p>
-
-<blockquote>
- <p>Once a facet reference is obtained from a locale object by
- calling use_facet&lt;&gt;, that reference remains usable, and the
- results from member functions of it may be cached and re-used, as
- long as some locale object refers to that facet.</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="32"></a>32. Pbackfail description inconsistent</h3>
-<p><b>Section:</b> 27.5.2.4.4 [streambuf.virt.pback] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The description of the required state before calling virtual member
-basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
-described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
-Specifically, the latter says it calls pbackfail if: </p>
-
-<p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>
-
-<p>where pbackfail claims to require: </p>
-
-<p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
-
-<p>It appears that the pbackfail description is wrong. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.5.2.4.4 [streambuf.virt.pback], paragraph 1, change:</p>
-
-<blockquote>
- <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
-</blockquote>
-
-<p>to </p>
-
-<blockquote>
- <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
- </p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>Note deliberate reordering of arguments for clarity in addition to the correction of
-the argument value.</p>
-
-
-
-
-
-<hr>
-<h3><a name="33"></a>33. Codecvt&lt;&gt; mentions from_type</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#43">43</a></p>
-<p><b>Discussion:</b></p>
-<p>In the table defining the results from do_out and do_in, the specification for the
-result <i>error</i> says </p>
-
-<blockquote>
- <p>encountered a from_type character it could not convert </p>
-</blockquote>
-
-<p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
-an internT for do_out. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 4, replace the definition
-in the table for the case of _error_ with </p>
-
-<blockquote>
- <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="34"></a>34. True/falsename() not in ctype&lt;&gt;</h3>
-<p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In paragraph 19, Effects:, members truename() and falsename are used from facet
-ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
-22.2.2.1.2, addressed in (4). </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.2.2 [facet.num.put.virtuals], paragraph 19, in the Effects:
-clause for member put(...., bool), replace the initialization of the
-string_type value s as follows: </p>
-
-<blockquote>
- <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
-string_type s = val ? np.truename() : np.falsename(); </pre>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="35"></a>35. No manipulator unitbuf in synopsis</h3>
-<p><b>Section:</b> 27.4 [iostreams.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 27.4.5.1 [fmtflags.manip], we have a definition for a manipulator
-named "unitbuf". Unlike other manipulators, it's not listed
-in synopsis. Similarly for "nounitbuf". </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add to the synopsis for &lt;ios&gt; in 27.4 [iostreams.base], after
-the entry for "nouppercase", the prototypes: </p>
-
-<blockquote>
- <pre>ios_base&amp; unitbuf(ios_base&amp; str);
-ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="36"></a>36. Iword &amp; pword storage lifetime omitted</h3>
-<p><b>Section:</b> 27.4.2.5 [ios.base.storage] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
-specified badly, so that an implementation which only keeps the last value stored appears
-to conform. In particular, it says: </p>
-
-<p>The reference returned may become invalid after another call to the object's iword
-member with a different index ... </p>
-
-<p>This is not idle speculation; at least one implementation was done this way. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add in 27.4.2.5 [ios.base.storage], in both paragraph 2 and also in
-paragraph 4, replace the sentence: </p>
-
-<blockquote>
- <p>The reference returned may become invalid after another call to the object's iword
- [pword] member with a different index, after a call to its copyfmt member, or when the
- object is destroyed. </p>
-</blockquote>
-
-<p>with: </p>
-
-<blockquote>
- <p>The reference returned is invalid after any other operations on the object. However,
- the value of the storage referred to is retained, so that until the next call to copyfmt,
- calling iword [pword] with the same index yields another reference to the same value. </p>
-</blockquote>
-
-<p>substituting "iword" or "pword" as appropriate. </p>
-
-
-
-
-
-<hr>
-<h3><a name="37"></a>37. Leftover "global" reference</h3>
-<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In the overview of locale semantics, paragraph 4, is the sentence </p>
-
-<blockquote>
- <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
- the standard exception bad_cast. </p>
-</blockquote>
-
-<p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
-from an old draft. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1 [locale], paragraph 4, delete the parenthesized
-expression </p>
-
-<blockquote>
- <p>(or, failing that, in the global locale) </p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="38"></a>38. Facet definition incomplete</h3>
-<p><b>Section:</b> 22.1.2 [locale.global.templates] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>It has been noticed by Esa Pulkkinen that the definition of
-"facet" is incomplete. In particular, a class derived from
-another facet, but which does not define a member <i>id</i>, cannot
-safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
-because there is no guarantee that a reference to the facet instance
-stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
-reads: </p>
-
-<blockquote>
- <p>Get a reference to a facet of a locale. </p>
-</blockquote>
-
-<p>with: </p>
-
-<blockquote>
- <p>Requires: <tt>Facet</tt> is a facet class whose definition
- contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 [locale.facet]. </p>
-</blockquote>
-
-<p><i>[
-Kona: strike as overspecification the text "(not inherits)"
-from the original resolution, which read "... whose definition
-contains (not inherits) the public static member
-<tt>id</tt>..."
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="39"></a>39. istreambuf_iterator&lt;&gt;::operator++(int) definition garbled</h3>
-<p><b>Section:</b> 24.5.3.4 [istreambuf.iterator::op++] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
-3, the standard contains three lines of garbage text left over from a previous edit. </p>
-
-<blockquote>
- <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
-sbuf_-&gt;sbumpc();
-return(tmp); </pre>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 24.5.3.4 [istreambuf.iterator::op++], delete the three lines of code at the
-end of paragraph 3. </p>
-
-
-
-
-
-<hr>
-<h3><a name="40"></a>40. Meaningless normative paragraph in examples</h3>
-<p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Paragraph 3 of the locale examples is a description of part of an
-implementation technique that has lost its referent, and doesn't mean
-anything. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Delete 22.2.8 [facets.examples] paragraph 3 which begins "This
-initialization/identification system depends...", or (at the
-editor's option) replace it with a place-holder to keep the paragraph
-numbering the same. </p>
-
-
-
-
-
-<hr>
-<h3><a name="41"></a>41. Ios_base needs clear(), exceptions()</h3>
-<p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#157">157</a></p>
-<p><b>Discussion:</b></p>
-<p>The description of ios_base::iword() and pword() in 27.4.2.4 [ios.members.static], say that if they fail, they "set badbit,
-which may throw an exception". However, ios_base offers no
-interface to set or to test badbit; those interfaces are defined in
-basic_ios&lt;&gt;. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the description in 27.4.2.5 [ios.base.storage] in
-paragraph 2, and also in paragraph 4, as follows. Replace</p>
-
-<blockquote>
- <p>If the function fails it sets badbit, which may throw an exception.</p>
-</blockquote>
-
-<p>with</p>
-
-<blockquote>
- <p>If the function fails, and <tt>*this</tt> is a base sub-object of
- a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
- equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
- on the derived object (which may throw <tt>failure</tt>).</p>
-</blockquote>
-
-<p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
-setstate(badbit).]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="42"></a>42. String ctors specify wrong default allocator</h3>
-<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The basic_string&lt;&gt; copy constructor: </p>
-
-<pre>basic_string(const basic_string&amp; str, size_type pos = 0,
- size_type n = npos, const Allocator&amp; a = Allocator()); </pre>
-
-<p>specifies an Allocator argument default value that is
-counter-intuitive. The natural choice for a the allocator to copy from
-is str.get_allocator(). Though this cannot be expressed in
-default-argument notation, overloading suffices. </p>
-
-<p>Alternatively, the other containers in Clause 23 (deque, list,
-vector) do not have this form of constructor, so it is inconsistent,
-and an evident source of confusion, for basic_string&lt;&gt; to have
-it, so it might better be removed. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p> In 21.3 [basic.string], replace the declaration of the copy
-constructor as follows: </p>
-
-<blockquote>
- <pre>basic_string(const basic_string&amp; str);
-basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
- const Allocator&amp; a = Allocator());</pre>
-</blockquote>
-
-<p>In 21.3.1 [string.require], replace the copy constructor declaration
-as above. Add to paragraph 5, Effects:</p>
-
-<blockquote>
- <p>In the first form, the Allocator value used is copied from
- <tt>str.get_allocator()</tt>.</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes the constructor is actually broken, rather than
-just an unfortunate design choice.</p>
-
-<p>The LWG considered two other possible resolutions:</p>
-
-<p>A. In 21.3 [basic.string], replace the declaration of the copy
-constructor as follows:</p>
-
-<blockquote>
- <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
- size_type n = npos);
-basic_string(const basic_string&amp; str, size_type pos,
- size_type n, const Allocator&amp; a); </pre>
-</blockquote>
-
-<p>In 21.3.1 [string.require], replace the copy constructor declaration
-as above. Add to paragraph 5, Effects: </p>
-
-<blockquote>
- <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
- value <tt>str.get_allocator()</tt>. </p>
-</blockquote>
-
-<p>B. In 21.3 [basic.string], and also in 21.3.1 [string.require], replace
-the declaration of the copy constructor as follows: </p>
-
-<blockquote>
- <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
- size_type n = npos); </pre>
-</blockquote>
-
-<p>The proposed resolution reflects the original intent of the LWG. It
-was also noted by Pete Becker that this fix "will cause
-a small amount of existing code to now work correctly."</p>
-
-<p><i>[
-Kona: issue editing snafu fixed - the proposed resolution now correctly
-reflects the LWG consensus.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="44"></a>44. Iostreams use operator== on int_type values</h3>
-<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Many of the specifications for iostreams specify that character
-values or their int_type equivalents are compared using operators ==
-or !=, though in other places traits::eq() or traits::eq_int_type is
-specified to be used throughout. This is an inconsistency; we should
-change uses of == and != to use the traits members instead. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
-
-
-<p>List of changes to clause 27:</p>
-<ol>
-<li>
- In lib.basic.ios.members paragraph 13 (postcondition clause for
- 'fill(cT)') change
-
-<blockquote><pre> fillch == fill()
-</pre></blockquote>
-
- to
-
-<blockquote><pre> traits::eq(fillch, fill())
-</pre></blockquote>
-
-
-</li>
-<li>
- In lib.istream.unformatted paragraph 7 (effects clause for
- 'get(cT,streamsize,cT)'), third bullet, change
-
-<blockquote><pre> c == delim for the next available input character c
-</pre></blockquote>
-
- to
-
-<blockquote><pre> traits::eq(c, delim) for the next available input character c
-</pre></blockquote>
-
-</li>
-<li>
- In lib.istream.unformatted paragraph 12 (effects clause for
- 'get(basic_streambuf&lt;cT,Tr&gt;&amp;,cT)'), third bullet, change
-
-<blockquote><pre> c == delim for the next available input character c
-</pre></blockquote>
-
- to
-
-<blockquote><pre> traits::eq(c, delim) for the next available input character c
-</pre></blockquote>
-
-</li>
-<li>
- In lib.istream.unformatted paragraph 17 (effects clause for
- 'getline(cT,streamsize,cT)'), second bullet, change
-
-<blockquote><pre> c == delim for the next available input character c
-</pre></blockquote>
-
- to
-
-<blockquote><pre> traits::eq(c, delim) for the next available input character c
- </pre></blockquote>
-
-</li>
-<li>
- In lib.istream.unformatted paragraph 24 (effects clause for
- 'ignore(int,int_type)'), second bullet, change
-
-<blockquote><pre> c == delim for the next available input character c
-</pre></blockquote>
-
- to
-
-<blockquote><pre> traits::eq_int_type(c, delim) for the next available input
- character c
-</pre></blockquote>
-
-</li>
-<li>
- In lib.istream.unformatted paragraph 25 (notes clause for
- 'ignore(int,int_type)'), second bullet, change
-
-<blockquote><pre> The last condition will never occur if delim == traits::eof()
-</pre></blockquote>
-
- to
-
-<blockquote><pre> The last condition will never occur if
- traits::eq_int_type(delim, traits::eof()).
-</pre></blockquote>
-
-</li>
-<li>
- In lib.istream.sentry paragraph 6 (example implementation for the
- sentry constructor) change
-
-<blockquote><pre> while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
-</pre></blockquote>
-
- to
-
-<blockquote><pre> while (!traits::eq_int_type(c = is.rdbuf()-&gt;snextc(), traits::eof())) {
-</pre></blockquote>
-
-</li>
-</ol>
-
-<p>List of changes to Chapter 21:</p>
-
-<ol>
-<li>
- In lib.string::find paragraph 1 (effects clause for find()),
- second bullet, change
-
-<blockquote><pre> at(xpos+I) == str.at(I) for all elements ...
-</pre></blockquote>
-
- to
-
-<blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ...
-</pre></blockquote>
-
-</li>
-<li>
- In lib.string::rfind paragraph 1 (effects clause for rfind()),
- second bullet, change
-
-<blockquote><pre> at(xpos+I) == str.at(I) for all elements ...
-</pre></blockquote>
-
- to
-
-<blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ...
-</pre></blockquote>
-
-</li>
-<li>
- In lib.string::find.first.of paragraph 1 (effects clause for
- find_first_of()), second bullet, change
-
-<blockquote><pre> at(xpos+I) == str.at(I) for all elements ...
-</pre></blockquote>
-
- to
-
-<blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ...
-</pre></blockquote>
-
-</li>
-<li>
- In lib.string::find.last.of paragraph 1 (effects clause for
- find_last_of()), second bullet, change
-
-<blockquote><pre> at(xpos+I) == str.at(I) for all elements ...
-</pre></blockquote>
-
- to
-
-<blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ...
-</pre></blockquote>
-
-</li>
-<li>
- In lib.string::find.first.not.of paragraph 1 (effects clause for
- find_first_not_of()), second bullet, change
-
-<blockquote><pre> at(xpos+I) == str.at(I) for all elements ...
-</pre></blockquote>
-
- to
-
-<blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ...
-</pre></blockquote>
-</li>
-
-<li>
- In lib.string::find.last.not.of paragraph 1 (effects clause for
- find_last_not_of()), second bullet, change
-
-<blockquote><pre> at(xpos+I) == str.at(I) for all elements ...
-</pre></blockquote>
-
- to
-
-<blockquote><pre> traits::eq(at(xpos+I), str.at(I)) for all elements ...
-</pre></blockquote>
-</li>
-
-<li>
- In lib.string.ios paragraph 5 (effects clause for getline()),
- second bullet, change
-
-<blockquote><pre> c == delim for the next available input character c
-</pre></blockquote>
-
- to
-
-<blockquote><pre> traits::eq(c, delim) for the next available input character c
-</pre></blockquote>
-</li>
-
-</ol>
-
-<p>Notes:</p>
-<ul>
-<li>
- Fixing this issue highlights another sloppyness in
- lib.istream.unformatted paragraph 24: this clause mentions a "character"
- which is then compared to an 'int_type' (see item 5. in the list
- below). It is not clear whether this requires explicit words and
- if so what these words are supposed to be. A similar issue exists,
- BTW, for operator*() of istreambuf_iterator which returns the result
- of sgetc() as a character type (see lib.istreambuf.iterator::op*
- paragraph 1), and for operator++() of istreambuf_iterator which
- passes the result of sbumpc() to a constructor taking a char_type
- (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
- assignment operator ostreambuf_iterator passes a char_type to a function
- taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
-</li>
-<li>
- It is inconsistent to use comparisons using the traits functions in
- Chapter 27 while not using them in Chapter 21, especially as some
- of the inconsistent uses actually involve streams (eg. getline() on
- streams). To avoid leaving this issue open still longer due to this
- inconsistency (it is open since 1998), a list of changes to Chapter
- 21 is below.
-</li>
-<li>
- In Chapter 24 there are several places with statements like "the end
- of stream is reached (streambuf_type::sgetc() returns traits::eof())"
- (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
- paragraph 5). It is unclear whether these should be clarified to use
- traits::eq_int_type() for detecting traits::eof().
-</li>
-</ul>
-
-
-
-
-
-
-<hr>
-<h3><a name="46"></a>46. Minor Annex D errors</h3>
-<p><b>Section:</b> D.7 [depr.str.strstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1998-06-01</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p><p>See lib-6522 and edit-814.</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>Change D.7.1 [depr.strstreambuf] (since streambuf is a typedef of
-basic_streambuf&lt;char&gt;) from:</p>
-
-<pre> virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>
-
-<p>to:</p>
-
-<pre> virtual streambuf* setbuf(char* s, streamsize n);</pre>
-
-<p>In D.7.4 [depr.strstream] insert the semicolon now missing after
-int_type:</p>
-
-<pre> namespace std {
- class strstream
- : public basic_iostream&lt;char&gt; {
- public:
- // Types
- typedef char char_type;
- typedef typename char_traits&lt;char&gt;::int_type int_type
- typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
-
-
-
-
-
-<hr>
-<h3><a name="47"></a>47. Imbue() and getloc() Returns clauses swapped</h3>
-<p><b>Section:</b> 27.4.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.locales">issues</a> in [ios.base.locales].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
-section has two RETURNS clauses, and they make no sense as
-stated. They make perfect sense, though, if you swap them. Am I
-correct in thinking that paragraphs 2 and 4 just got mixed up by
-accident?</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.4.2.3 [ios.base.locales] swap paragraphs 2 and 4.</p>
-
-
-
-
-
-<hr>
-<h3><a name="48"></a>48. Use of non-existent exception constructor</h3>
-<p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>27.4.2.1.1, paragraph 2, says that class failure initializes the
-base class, exception, with exception(msg). Class exception (see
-18.6.1) has no such constructor.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace 27.4.2.1.1 [ios::failure], paragraph 2, with</p>
-
-<blockquote>
- <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="49"></a>49. Underspecification of ios_base::sync_with_stdio</h3>
-<p><b>Section:</b> 27.4.2.4 [ios.members.static] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Two problems</p>
-
-<p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
-returns. Does it return f, or does it return the previous
-synchronization state? My guess is the latter, but the standard
-doesn't say so.</p>
-
-<p>(2) 27.4.2.4 doesn't say what it means for streams to be
-synchronized with stdio. Again, of course, I can make some
-guesses. (And I'm unhappy about the performance implications of those
-guesses, but that's another matter.)</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the following sentence in 27.4.2.4 [ios.members.static]
-returns clause from:</p>
-
-<blockquote>
- <p><tt>true</tt> if the standard iostream objects (27.3) are
- synchronized and otherwise returns <tt>false</tt>.</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- <p><tt>true</tt> if the previous state of the standard iostream
- objects (27.3) was synchronized and otherwise returns
- <tt>false</tt>.</p>
-</blockquote>
-
-<p>Add the following immediately after 27.4.2.4 [ios.members.static],
-paragraph 2:</p>
-
-<blockquote>
-<p>When a standard iostream object str is <i>synchronized</i> with a
-standard stdio stream f, the effect of inserting a character c by</p>
-<pre> fputc(f, c);
-</pre>
-
-<p>is the same as the effect of</p>
-<pre> str.rdbuf()-&gt;sputc(c);
-</pre>
-
-<p>for any sequence of characters; the effect of extracting a
-character c by</p>
-<pre> c = fgetc(f);
-</pre>
-
-<p>is the same as the effect of:</p>
-<pre> c = str.rdbuf()-&gt;sbumpc(c);
-</pre>
-
-<p>for any sequences of characters; and the effect of pushing
-back a character c by</p>
-<pre> ungetc(c, f);
-</pre>
-
-<p>is the same as the effect of</p>
-<pre> str.rdbuf()-&gt;sputbackc(c);
-</pre>
-
-<p>for any sequence of characters. [<i>Footnote</i>: This implies
-that operations on a standard iostream object can be mixed arbitrarily
-with operations on the corresponding stdio stream. In practical
-terms, synchronization usually means that a standard iostream object
-and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
-</blockquote>
-
-<p><i>[pre-Copenhagen: PJP and Matt contributed the definition
-of "synchronization"]</i></p>
-
-
-<p><i>[post-Copenhagen: proposed resolution was revised slightly:
-text was added in the non-normative footnote to say that operations
-on the two streams can be mixed arbitrarily.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="50"></a>50. Copy constructor and assignment operator of ios_base</h3>
-<p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>As written, ios_base has a copy constructor and an assignment
-operator. (Nothing in the standard says it doesn't have one, and all
-classes have copy constructors and assignment operators unless you
-take specific steps to avoid them.) However, nothing in 27.4.2 says
-what the copy constructor and assignment operator do. </p>
-
-<p>My guess is that this was an oversight, that ios_base is, like
-basic_ios, not supposed to have a copy constructor or an assignment
-operator.</p>
-
-<p>
-Jerry Schwarz comments: Yes, its an oversight, but in the opposite
-sense to what you're suggesting. At one point there was a definite
-intention that you could copy ios_base. It's an easy way to save the
-entire state of a stream for future use. As you note, to carry out
-that intention would have required a explicit description of the
-semantics (e.g. what happens to the iarray and parray stuff).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.4.2 [ios.base], class ios_base, specify the copy
-constructor and operator= members as being private.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes the difficulty of specifying correct semantics
-outweighs any benefit of allowing ios_base objects to be copyable.</p>
-
-
-
-
-
-<hr>
-<h3><a name="51"></a>51. Requirement to not invalidate iterators missing</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> David Vandevoorde <b>Date:</b> 1998-06-23</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The std::sort algorithm can in general only sort a given sequence
-by moving around values. The list&lt;&gt;::sort() member on the other
-hand could move around values or just update internal pointers. Either
-method can leave iterators into the list&lt;&gt; dereferencable, but
-they would point to different things. </p>
-
-<p>Does the FDIS mandate anywhere which method should be used for
-list&lt;&gt;::sort()?</p>
-
-<p>Matt Austern comments:</p>
-
-<p>I think you've found an omission in the standard. </p>
-
-<p>The library working group discussed this point, and there was
-supposed to be a general requirement saying that list, set, map,
-multiset, and multimap may not invalidate iterators, or change the
-values that iterators point to, except when an operation does it
-explicitly. So, for example, insert() doesn't invalidate any iterators
-and erase() and remove() only invalidate iterators pointing to the
-elements that are being erased. </p>
-
-<p>I looked for that general requirement in the FDIS, and, while I
-found a limited form of it for the sorted associative containers, I
-didn't find it for list. It looks like it just got omitted. </p>
-
-<p>The intention, though, is that list&lt;&gt;::sort does not
-invalidate any iterators and does not change the values that any
-iterator points to. There would be no reason to have the member
-function otherwise.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add a new paragraph at the end of 23.1:</p>
-
-<blockquote>
- <p>Unless otherwise specified (either explicitly or by defining a function in terms of
- other functions), invoking a container member function or passing a container as an
- argument to a library function shall not invalidate iterators to, or change the values of,
- objects within that container. </p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>This was US issue CD2-23-011; it was accepted in London but the
-change was not made due to an editing oversight. The wording in the
-proposed resolution below is somewhat updated from CD2-23-011,
-particularly the addition of the phrase "or change the values
-of"</p>
-
-
-
-
-
-<hr>
-<h3><a name="52"></a>52. Small I/O problems</h3>
-<p><b>Section:</b> 27.4.3.2 [fpos.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>First, 27.4.4.1 [basic.ios.cons], table 89. This is pretty obvious:
-it should be titled "basic_ios&lt;&gt;() effects", not
-"ios_base() effects". </p>
-
-<p>[The second item is a duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#6">6</a> for
-resolution.]</p>
-
-<p>Second, 27.4.3.2 [fpos.operations] table 88 . There are a couple
-different things wrong with it, some of which I've already discussed
-with Jerry, but the most obvious mechanical sort of error is that it
-uses expressions like P(i) and p(i), without ever defining what sort
-of thing "i" is.
-</p>
-
-<p>(The other problem is that it requires support for streampos
-arithmetic. This is impossible on some systems, i.e. ones where file
-position is a complicated structure rather than just a number. Jerry
-tells me that the intention was to require syntactic support for
-streampos arithmetic, but that it wasn't actually supposed to do
-anything meaningful except on platforms, like Unix, where genuine
-arithmetic is possible.) </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 27.4.4.1 [basic.ios.cons] table 89 title from
-"ios_base() effects" to "basic_ios&lt;&gt;()
-effects". </p>
-
-
-
-
-
-<hr>
-<h3><a name="53"></a>53. Basic_ios destructor unspecified</h3>
-<p><b>Section:</b> 27.4.4.1 [basic.ios.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.cons">issues</a> in [basic.ios.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
-The important question is whether basic_ios::~basic_ios() destroys
-rdbuf().</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add after 27.4.4.1 [basic.ios.cons] paragraph 2:</p>
-
-<blockquote>
- <p><tt>virtual ~basic_ios();</tt></p>
- <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG reviewed the additional question of whether or not
-<tt>rdbuf(0)</tt> may set <tt>badbit</tt>. The answer is
-clearly yes; it may be set via <tt>clear()</tt>. See 27.4.4.2 [basic.ios.members], paragraph 6. This issue was reviewed at length
-by the LWG, which removed from the original proposed resolution a
-footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
-<tt>badbit</tt>".</p>
-
-
-
-
-
-<hr>
-<h3><a name="54"></a>54. Basic_streambuf's destructor</h3>
-<p><b>Section:</b> 27.5.2.1 [streambuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.cons">issues</a> in [streambuf.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The class synopsis for basic_streambuf shows a (virtual)
-destructor, but the standard doesn't say what that destructor does. My
-assumption is that it does nothing, but the standard should say so
-explicitly. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add after 27.5.2.1 [streambuf.cons] paragraph 2:</p>
-
-<blockquote>
- <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
- <p><b>Effects</b>: None.</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="55"></a>55. Invalid stream position is undefined</h3>
-<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Several member functions in clause 27 are defined in certain
-circumstances to return an "invalid stream position", a term
-that is defined nowhere in the standard. Two places (27.5.2.4.2,
-paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
-a definition in _lib.iostreams.definitions_, a nonexistent
-section. </p>
-
-<p>I suspect that the invalid stream position is just supposed to be
-pos_type(-1). Probably best to say explicitly in (for example)
-27.5.2.4.2 that the return value is pos_type(-1), rather than to use
-the term "invalid stream position", define that term
-somewhere, and then put in a cross-reference. </p>
-
-<p>The phrase "invalid stream position" appears ten times in
-the C++ Standard. In seven places it refers to a return value, and it
-should be changed. In three places it refers to an argument, and it
-should not be changed. Here are the three places where "invalid
-stream position" should not be changed:</p>
-
-<blockquote>
- <p>27.7.1.4 [stringbuf.virtuals], paragraph 14<br>
- 27.8.1.5 [filebuf.virtuals], paragraph 14<br>
- D.7.1.3 [depr.strstreambuf.virtuals], paragraph 17
- </p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 4, change "Returns an
-object of class pos_type that stores an invalid stream position
-(_lib.iostreams.definitions_)" to "Returns
-<tt>pos_type(off_type(-1))</tt>".
-</p>
-
-<p>In 27.5.2.4.2 [streambuf.virt.buffer], paragraph 6, change "Returns
-an object of class pos_type that stores an invalid stream
-position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
-
-<p>In 27.7.1.4 [stringbuf.virtuals], paragraph 13, change "the object
-stores an invalid stream position" to "the return value is
-<tt>pos_type(off_type(-1))</tt>". </p>
-
-<p>In 27.8.1.5 [filebuf.virtuals], paragraph 13, change "returns an
-invalid stream position (27.4.3)" to "returns
-<tt>pos_type(off_type(-1))</tt>" </p>
-
-<p>In 27.8.1.5 [filebuf.virtuals], paragraph 15, change "Otherwise
-returns an invalid stream position (_lib.iostreams.definitions_)"
-to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
-</p>
-
-<p>In D.7.1.3 [depr.strstreambuf.virtuals], paragraph 15, change "the object
-stores an invalid stream position" to "the return value is
-<tt>pos_type(off_type(-1))</tt>" </p>
-
-<p>In D.7.1.3 [depr.strstreambuf.virtuals], paragraph 18, change "the object
-stores an invalid stream position" to "the return value is
-<tt>pos_type(off_type(-1))</tt>"</p>
-
-
-
-
-
-<hr>
-<h3><a name="56"></a>56. Showmanyc's return type</h3>
-<p><b>Section:</b> 27.5.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-06-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
-showmanyc has return type int. However, 27.5.2.4.3 says that its
-return type is streamsize. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change <tt>showmanyc</tt>'s return type in the
-27.5.2 [streambuf] class summary to <tt>streamsize</tt>.</p>
-
-
-
-
-
-<hr>
-<h3><a name="57"></a>57. Mistake in char_traits</h3>
-<p><b>Section:</b> 21.1.3.4 [char.traits.specializations.wchar.t] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-01</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>21.1.3.2, paragraph 3, says "The types streampos and
-wstreampos may be different if the implementation supports no shift
-encoding in narrow-oriented iostreams but supports one or more shift
-encodings in wide-oriented streams". </p>
-
-<p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
-in 27.2 says that streampos and wstreampos are, respectively, synonyms
-for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
-fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
-to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
-char_traits&lt;char&gt;::state_type and
-char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Remove the sentence in 21.1.3.4 [char.traits.specializations.wchar.t] paragraph 3 which
-begins "The types streampos and wstreampos may be
-different..." . </p>
-
-
-
-
-
-<hr>
-<h3><a name="59"></a>59. Ambiguity in specification of gbump</h3>
-<p><b>Section:</b> 27.5.2.3.2 [streambuf.get.area] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-07-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
-next pointer for the input sequence by n." </p>
-
-<p>The straightforward interpretation is that it is just gptr() +=
-n. An alternative interpretation, though, is that it behaves as if it
-calls sbumpc n times. (The issue, of course, is whether it might ever
-call underflow.) There is a similar ambiguity in the case of
-pbump. </p>
-
-<p>(The "classic" AT&amp;T implementation used the
-former interpretation.)</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 27.5.2.3.2 [streambuf.get.area] paragraph 4 gbump effects from:</p>
-
-<blockquote>
- <p>Effects: Advances the next pointer for the input sequence by n.</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
- <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
-</blockquote>
-
-<p>Make the same change to 27.5.2.3.3 [streambuf.put.area] paragraph 4 pbump
-effects.</p>
-
-
-
-
-
-<hr>
-<h3><a name="60"></a>60. What is a formatted input function?</h3>
-<p><b>Section:</b> 27.6.1.2.1 [istream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#163">163</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a></p>
-<p><b>Discussion:</b></p>
-<p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
-formatted input functions. Some of the functions defined in section
-27.6.1.2 explicitly say that those requirements apply ("Behaves
-like a formatted input member (as described in 27.6.1.2.1)"), but
-others don't. The question: is 27.6.1.2.1 supposed to apply to
-everything in 27.6.1.2, or only to those member functions that
-explicitly say "behaves like a formatted input member"? Or
-to put it differently: are we to assume that everything that appears
-in a section called "Formatted input functions" really is a
-formatted input function? I assume that 27.6.1.2.1 is intended to
-apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
-is not intended to apply to extractors like </p>
-
-<pre> basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>
-
-<p>and </p>
-
-<pre> basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>
-
-<p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
-output. </p>
-
-<p>Comments from Judy Ward: It seems like the problem is that the
-basic_istream and basic_ostream operator &lt;&lt;()'s that are used
-for the manipulators and streambuf* are in the wrong section and
-should have their own separate section or be modified to make it clear
-that the "Common requirements" listed in section 27.6.1.2.1
-(for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
-apply to them. </p>
-
-<p>Additional comments from Dietmar Khl: It appears to be somewhat
-nonsensical to consider the functions defined in 27.6.1.2.3
-[istream::extractors] paragraphs 1 to 5 to be "Formatted input
-function" but since these functions are defined in a section
-labeled "Formatted input functions" it is unclear to me
-whether these operators are considered formatted input functions which
-have to conform to the "common requirements" from 27.6.1.2.1
-[istream.formatted.reqmts]: If this is the case, all manipulators, not
-just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
-set (... but setting <tt>noskipws</tt> using the manipulator syntax
-would also skip whitespace :-)</p> <p>It is not clear which functions
-are to be considered unformatted input functions. As written, it seems
-that all functions in 27.6.1.3 [istream.unformatted] are unformatted input
-functions. However, it does not really make much sense to construct a
-sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
-unclear what happens to the <tt>gcount()</tt> if
-eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
-<tt>sync()</tt> is called: These functions don't extract characters,
-some of them even "unextract" a character. Should this still
-be reflected in <tt>gcount()</tt>? Of course, it could be read as if
-after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
-(the last unformatted input function, <tt>gcount()</tt>, didn't
-extract any character) and after a call to <tt>putback()</tt>
-<tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
-function <tt>putback()</tt> did "extract" back into the
-stream). Correspondingly for <tt>unget()</tt>. Is this what is
-intended? If so, this should be clarified. Otherwise, a corresponding
-clarification should be used.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
-Change the beginning of the second sentence from "The conversion
-occurs" to "These extractors behave as formatted input functions (as
-described in 27.6.1.2.1). After a sentry object is constructed,
-the conversion occurs"
-</p>
-
-<p>
-In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
-Add an effects clause. "Effects: None. This extractor does
-not behave as a formatted input function (as described in
-27.6.1.2.1).
-</p>
-
-<p>
-In 27.6.1.2.3, [lib.istream::extractors], paragraph 2. Change the
-effects clause to "Effects: Calls pf(*this). This extractor does not
-behave as a formatted input function (as described in 27.6.1.2.1).
-</p>
-
-<p>
-In 27.6.1.2.3, [lib.istream::extractors], paragraph 4. Change the
-effects clause to "Effects: Calls pf(*this). This extractor does not
-behave as a formatted input function (as described in 27.6.1.2.1).
-</p>
-
-<p>
-In 27.6.1.2.3, [lib.istream::extractors], paragraph 12. Change the
-first two sentences from "If sb is null, calls setstate(failbit),
-which may throw ios_base::failure (27.4.4.3). Extracts characters
-from *this..." to "Behaves as a formatted input function (as described
-in 27.6.1.2.1). If sb is null, calls setstate(failbit), which may
-throw ios_base::failure (27.4.4.3). After a sentry object is
-constructed, extracts characters from *this...".
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], before paragraph 2. Add an
-effects clause. "Effects: none. This member function does not behave
-as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 3. Change the
-beginning of the first sentence of the effects clause from "Extracts a
-character" to "Behaves as an unformatted input function (as described
-in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a
-character"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the
-beginning of the first sentence of the effects clause from "Extracts a
-character" to "Behaves as an unformatted input function (as described
-in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a
-character"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 7. Change the
-beginning of the first sentence of the effects clause from "Extracts
-characters" to "Behaves as an unformatted input function (as described
-in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
-characters"
-</p>
-
-<p>
-[No change needed in paragraph 10, because it refers to paragraph 7.]
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 12. Change the
-beginning of the first sentence of the effects clause from "Extracts
-characters" to "Behaves as an unformatted input function (as described
-in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
-characters"
-</p>
-
-<p>
-[No change needed in paragraph 15.]
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 17. Change the
-beginning of the first sentence of the effects clause from "Extracts
-characters" to "Behaves as an unformatted input function (as described
-in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
-characters"
-</p>
-
-<p>
-[No change needed in paragraph 23.]
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 24. Change the
-beginning of the first sentence of the effects clause from "Extracts
-characters" to "Behaves as an unformatted input function (as described
-in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts
-characters"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], before paragraph 27. Add an
-Effects clause: "Effects: Behaves as an unformatted input function (as
-described in 27.6.1.3, paragraph 1). After constructing a sentry
-object, reads but does not extract the current input character."
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 28. Change the
-first sentence of the Effects clause from "If !good() calls" to
-Behaves as an unformatted input function (as described in 27.6.1.3,
-paragraph 1). After constructing a sentry object, if !good() calls"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 30. Change the
-first sentence of the Effects clause from "If !good() calls" to
-"Behaves as an unformatted input function (as described in 27.6.1.3,
-paragraph 1). After constructing a sentry object, if !good() calls"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 32. Change the
-first sentence of the Effects clause from "If !good() calls..." to
-"Behaves as an unformatted input function (as described in 27.6.1.3,
-paragraph 1). After constructing a sentry object, if !good()
-calls..." Add a new sentence to the end of the Effects clause:
-"[Note: this function extracts no characters, so the value returned
-by the next call to gcount() is 0.]"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 34. Change the
-first sentence of the Effects clause from "If !good() calls" to
-"Behaves as an unformatted input function (as described in 27.6.1.3,
-paragraph 1). After constructing a sentry object, if !good() calls".
-Add a new sentence to the end of the Effects clause: "[Note: this
-function extracts no characters, so the value returned by the next
-call to gcount() is 0.]"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 36. Change the
-first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
-as an unformatted input function (as described in 27.6.1.3, paragraph
-1), except that it does not count the number of characters extracted
-and does not affect the value returned by subsequent calls to
-gcount(). After constructing a sentry object, if rdbuf() is"
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], before paragraph 37. Add an
-Effects clause: "Effects: Behaves as an unformatted input function (as
-described in 27.6.1.3, paragraph 1), except that it does not count the
-number of characters extracted and does not affect the value returned
-by subsequent calls to gcount()." Change the first sentence of
-paragraph 37 from "if fail()" to "after constructing a sentry object,
-if fail()".
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 38. Change the
-first sentence of the Effects clause from "If fail()" to "Behaves
-as an unformatted input function (as described in 27.6.1.3, paragraph
-1), except that it does not count the number of characters extracted
-and does not affect the value returned by subsequent calls to
-gcount(). After constructing a sentry object, if fail()
-</p>
-
-<p>
-In 27.6.1.3, [lib.istream.unformatted], paragraph 40. Change the
-first sentence of the Effects clause from "If fail()" to "Behaves
-as an unformatted input function (as described in 27.6.1.3, paragraph
-1), except that it does not count the number of characters extracted
-and does not affect the value returned by subsequent calls to
-gcount(). After constructing a sentry object, if fail()
-</p>
-
-<p>
-In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1. Change
-the beginning of the third sentence from "The formatting conversion"
-to "These extractors behave as formatted output functions (as
-described in 27.6.2.5.1). After the sentry object is constructed, the
-conversion occurs".
-</p>
-
-<p>
-In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1. Add an
-effects clause: "Effects: None. Does not behave as a formatted output
-function (as described in 27.6.2.5.1).".
-</p>
-
-<p>
-In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2. Change the
-effects clause to "Effects: calls pf(*this). This extractor does not
-behave as a formatted output function (as described in 27.6.2.5.1).".
-</p>
-
-<p>
-In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4. Change the
-effects clause to "Effects: calls pf(*this). This extractor does not
-behave as a formatted output function (as described in 27.6.2.5.1).".
-</p>
-
-<p>
-In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6. Change the first
-sentence from "If sb" to "Behaves as a formatted output function (as
-described in 27.6.2.5.1). After the sentry object is constructed, if
-sb".
-</p>
-
-<p>
-In 27.6.2.6 [lib.ostream.unformatted], paragraph 2. Change the first
-sentence from "Inserts the character" to "Behaves as an unformatted
-output function (as described in 27.6.2.6, paragraph 1). After
-constructing a sentry object, inserts the character".
-</p>
-
-<p>
-In 27.6.2.6 [lib.ostream.unformatted], paragraph 5. Change the first
-sentence from "Obtains characters" to "Behaves as an unformatted
-output function (as described in 27.6.2.6, paragraph 1). After
-constructing a sentry object, obtains characters".
-</p>
-
-<p>
-In 27.6.2.6 [lib.ostream.unformatted], paragraph 7. Add a new
-sentence at the end of the paragraph: "Does not behave as an
-unformatted output function (as described in 27.6.2.6, paragraph 1)."
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
-by Judy Ward and Matt Austern. This proposed resolution is section
-VI of that paper.</p>
-
-
-
-
-
-<hr>
-<h3><a name="61"></a>61. Ambiguity in iostreams exception policy</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The introduction to the section on unformatted input (27.6.1.3)
-says that every unformatted input function catches all exceptions that
-were thrown during input, sets badbit, and then conditionally rethrows
-the exception. That seems clear enough. Several of the specific
-functions, however, such as get() and read(), are documented in some
-circumstances as setting eofbit and/or failbit. (The standard notes,
-correctly, that setting eofbit or failbit can sometimes result in an
-exception being thrown.) The question: if one of these functions
-throws an exception triggered by setting failbit, is this an exception
-"thrown during input" and hence covered by 27.6.1.3, or does
-27.6.1.3 only refer to a limited class of exceptions? Just to make
-this concrete, suppose you have the following snippet. </p>
-
-<pre>
- char buffer[N];
- istream is;
- ...
- is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
- is.read(buffer, N);</pre>
-
-<p>Now suppose we reach EOF before we've read N characters. What
-iostate bits can we expect to be set, and what exception (if any) will
-be thrown? </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.6.1.3, paragraph 1, after the sentence that begins
-"If an exception is thrown...", add the following
-parenthetical comment: "(Exceptions thrown from
-<tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG looked to two alternative wordings, and choose the proposed
-resolution as better standardese.</p>
-
-
-
-
-
-<hr>
-<h3><a name="62"></a>62. <tt>Sync</tt>'s return value</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
-"calls rdbuf()-&gt;pubsync() and, if that function returns -1
-... returns traits::eof()." </p>
-
-<p>That looks suspicious, because traits::eof() is of type
-traits::int_type while the return type of sync() is int. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.3 [istream.unformatted], paragraph 36, change "returns
-<tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="63"></a>63. Exception-handling policy for unformatted output</h3>
-<p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Clause 27 details an exception-handling policy for formatted input,
-unformatted input, and formatted output. It says nothing for
-unformatted output (27.6.2.6). 27.6.2.6 should either include the same
-kind of exception-handling policy as in the other three places, or
-else it should have a footnote saying that the omission is
-deliberate. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.6.2.6, paragraph 1, replace the last sentence ("In any
-case, the unformatted output function ends by destroying the sentry
-object, then returning the value specified for the formatted output
-function.") with the following text:
-</p>
-<blockquote><p>
-If an exception is thrown during output, then <tt>ios::badbit</tt> is
-turned on [Footnote: without causing an <tt>ios::failure</tt> to be
-thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
-badbit) != 0</tt> then the exception is rethrown. In any case, the
-unformatted output function ends by destroying the sentry object,
-then, if no exception was thrown, returning the value specified for
-the formatted output function.
-</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>
-This exception-handling policy is consistent with that of formatted
-input, unformatted input, and formatted output.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="64"></a>64. Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt></h3>
-<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
-different ways, depending on whether the second sentence is read as an
-elaboration of the first. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace 27.6.1.2.3 [istream::extractors], paragraph 13, which begins
-"If the function inserts no characters ..." with:</p>
-
-<blockquote>
- <p>If the function inserts no characters, it calls
- <tt>setstate(failbit)</tt>, which may throw
- <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
- because it caught an exception thrown while extracting characters
- from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
- (27.4.4.3), then the caught exception is rethrown. </p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="66"></a>66. Strstreambuf::setbuf</h3>
-<p><b>Section:</b> D.7.1.3 [depr.strstreambuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-08-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.strstreambuf.virtuals">issues</a> in [depr.strstreambuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
-"Performs an operation that is defined separately for each class
-derived from strstreambuf". This is obviously an incorrect
-cut-and-paste from basic_streambuf. There are no classes derived from
-strstreambuf. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>D.7.1.3 [depr.strstreambuf.virtuals], paragraph 19, replace the setbuf effects
-clause which currently says "Performs an operation that is
-defined separately for each class derived from strstreambuf"
-with:</p>
-
-<blockquote>
- <p><b>Effects</b>: implementation defined, except that
- <tt>setbuf(0,0)</tt> has no effect.</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="68"></a>68. Extractors for char* should store null at end</h3>
-<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1998-07-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Extractors for char* (27.6.1.2.3) do not store a null character
-after the extracted character sequence whereas the unformatted
-functions like get() do. Why is this?</p>
-
-<p>Comment from Jerry Schwarz: There is apparently an editing
-glitch. You'll notice that the last item of the list of what stops
-extraction doesn't make any sense. It was supposed to be the line that
-said a null is stored.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>27.6.1.2.3 [istream::extractors], paragraph 7, change the last list
-item from:</p>
-
-<blockquote><p>
- A null byte (<tt>charT()</tt>) in the next position, which may be
- the first position if no characters were extracted.
-</p></blockquote>
-
-<p>to become a new paragraph which reads:</p>
-
-<blockquote><p>
- Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
- next position, which may be the first position if no characters were
- extracted.
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="69"></a>69. Must elements of a vector be contiguous?</h3>
-<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1998-07-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
-
-<p>(Please note that this is entirely separate from the question of
-whether a vector iterator is required to be a pointer; the answer to
-that question is clearly "no," as it would rule out
-debugging implementations)</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add the following text to the end of 23.2.6 [vector],
-paragraph 1. </p>
-
-<blockquote>
- <p>The elements of a vector are stored contiguously, meaning that if
- v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
- other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
- == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG feels that as a practical matter the answer is clearly
-"yes". There was considerable discussion as to the best way
-to express the concept of "contiguous", which is not
-directly defined in the standard. Discussion included:</p>
-
-<ul>
- <li>An operational definition similar to the above proposed resolution is
- already used for valarray (26.5.2.3 [valarray.access]).</li>
- <li>There is no need to explicitly consider a user-defined operator&amp;
- because elements must be copyconstructible (23.1 [container.requirements] para 3)
- and copyconstructible (20.1.1 [utility.arg.requirements]) specifies
- requirements for operator&amp;.</li>
- <li>There is no issue of one-past-the-end because of language rules.</li>
-</ul>
-
-
-
-
-
-<hr>
-<h3><a name="70"></a>70. Uncaught_exception() missing throw() specification</h3>
-<p><b>Section:</b> 18.7 [support.exception], 18.7.4 [uncaught] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-08-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.exception">issues</a> in [support.exception].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
-
-<p>uncaught_exception() doesn't have a throw specification.</p>
-
-<p>It is intentional ? Does it means that one should be prepared to
-handle exceptions thrown from uncaught_exception() ?</p>
-
-<p>uncaught_exception() is called in exception handling contexts where
-exception safety is very important.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 15.5.3 [except.uncaught], paragraph 1, 18.7 [support.exception],
-and 18.7.4 [uncaught], add "throw()" to uncaught_exception().</p>
-
-
-
-
-<hr>
-<h3><a name="71"></a>71. Do_get_monthname synopsis missing argument</h3>
-<p><b>Section:</b> 22.2.5.1 [locale.time.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-08-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
-is described in 22.2.5.1.2 [locale.time.get.virtuals] with five arguments,
-consistent with do_get_weekday and with its specified use by member
-get_monthname. However, in the synopsis, it is specified instead with
-four arguments. The missing argument is the "end" iterator
-value.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.5.1 [locale.time.get], add an "end" argument to
-the declaration of member do_monthname as follows:</p>
-
-<pre> virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
- ios_base::iostate&amp; err, tm* t) const;</pre>
-
-
-
-
-<hr>
-<h3><a name="74"></a>74. Garbled text for <tt>codecvt::do_max_length</tt></h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-09-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
-clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
-parentheses and a spurious <b>n</b>.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 11 with the
-following:</p>
-
-<blockquote><p>
- <b>Returns</b>: The maximum value that
- <tt>do_length(state, from, from_end, 1)</tt> can return for any
- valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
- <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
- mbstate_t&gt;::do_max_length()</tt> returns 1.
-</p></blockquote>
-
-
-
-
-<hr>
-<h3><a name="75"></a>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt
-Austern <b>Date:</b> 1998-09-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
-and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
-parameter of the member functions <tt>length</tt> and
-<tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
-function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
-paragraph 9) say that the type is <tt>stateT&amp;</tt>. Either the
-synopsis or the summary must be changed. </p>
-
-<p>If (as I believe) the member function descriptions are correct,
-then we must also add text saying how <tt>do_length</tt> changes its
-<tt>stateT</tt> argument. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.4 [locale.codecvt], and also in 22.2.1.5 [locale.codecvt.byname],
-change the <tt>stateT</tt> argument type on both member
-<tt>length()</tt> and member <tt>do_length()</tt> from </p>
-
-<blockquote>
- <p><tt>const stateT&amp;</tt></p>
-</blockquote>
-
-<p>to</p>
-
-<blockquote>
- <p><tt>stateT&amp;</tt></p>
-</blockquote>
-
-<p>In 22.2.1.4.2 [locale.codecvt.virtuals], add to the definition for member
-<tt>do_length</tt> a paragraph:</p>
-
-<blockquote>
- <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
- it called <tt>do_in(state, from, from_end, from, to, to+max,
- to)</tt> for <tt>to</tt> pointing to a buffer of at least
- <tt>max</tt> elements.</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="76"></a>76. Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3>
-<p><b>Section:</b> 22.2.1.4 [locale.codecvt] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-09-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt">issues</a> in [locale.codecvt].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>This issue concerns the requirements on classes derived from
-<tt>codecvt</tt>, including user-defined classes. What are the
-restrictions on the conversion from external characters
-(e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
-Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
-the I/O library make? </p>
-
-<p>The question is whether it's possible to convert from internal
-characters to external characters one internal character at a time,
-and whether, given a valid sequence of external characters, it's
-possible to pick off internal characters one at a time. Or, to put it
-differently: given a sequence of external characters and the
-corresponding sequence of internal characters, does a position in the
-internal sequence correspond to some position in the external
-sequence? </p>
-
-<p>To make this concrete, suppose that <tt>[first, last)</tt> is a
-sequence of <i>M</i> external characters and that <tt>[ifirst,
-ilast)</tt> is the corresponding sequence of <i>N</i> internal
-characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
-applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
-ilast)</tt>. Now the question: does there necessarily exist a
-subsequence of external characters, <tt>[first, last_1)</tt>, such
-that the corresponding sequence of internal characters is the single
-character <tt>*ifirst</tt>?
-</p>
-
-<p>(What a "no" answer would mean is that
-<tt>my_encoding</tt> translates sequences only as blocks. There's a
-sequence of <i>M</i> external characters that maps to a sequence of
-<i>N</i> internal characters, but that external sequence has no
-subsequence that maps to <i>N-1</i> internal characters.) </p>
-
-<p>Some of the wording in the standard, such as the description of
-<tt>codecvt::do_max_length</tt> (22.2.1.4.2 [locale.codecvt.virtuals],
-paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.5 [filebuf.virtuals], paragraph 3) suggests that it must always be
-possible to pick off internal characters one at a time from a sequence
-of external characters. However, this is never explicitly stated one
-way or the other. </p>
-
-<p>This issue seems (and is) quite technical, but it is important if
-we expect users to provide their own encoding facets. This is an area
-where the standard library calls user-supplied code, so a well-defined
-set of requirements for the user-supplied code is crucial. Users must
-be aware of the assumptions that the library makes. This issue affects
-positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
-and several of <tt>codecvt</tt>'s member functions. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add the following text as a new paragraph, following 22.2.1.4.2 [locale.codecvt.virtuals] paragraph 2:</p>
-
-<blockquote>
-<p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
-(27.8 [file.streams]) must have the property that if</p>
-<pre> do_out(state, from, from_end, from_next, to, to_lim, to_next)
-</pre>
-<p>would return <tt>ok</tt>, where <tt>from != from_end</tt>, then </p>
-<pre> do_out(state, from, from + 1, from_next, to, to_end, to_next)
-</pre>
-<p>must also return <tt>ok</tt>, and that if</p>
-<pre> do_in(state, from, from_end, from_next, to, to_lim, to_next)
-</pre>
-<p>would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then</p>
-<pre> do_in(state, from, from_end, from_next, to, to + 1, to_next)
-</pre>
-<p>must also return <tt>ok</tt>. [<i>Footnote:</i> Informally, this
-means that <tt>basic_filebuf</tt> assumes that the mapping from
-internal to external characters is 1 to N: a <tt>codecvt</tt> that is
-used by <tt>basic_filebuf</tt> must be able to translate characters
-one internal character at a time. <i>--End Footnote</i>]</p>
-</blockquote>
-
-<p><i>[Redmond: Minor change in proposed resolution. Original
-proposed resolution talked about "success", with a parenthetical
-comment that success meant returning <tt>ok</tt>. New wording
-removes all talk about "success", and just talks about the
-return value.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-
- <p>The proposed resoluion says that conversions can be performed one
- internal character at a time. This rules out some encodings that
- would otherwise be legal. The alternative answer would mean there
- would be some internal positions that do not correspond to any
- external file position.</p>
- <p>
- An example of an encoding that this rules out is one where the
- <tt>internT</tt> and <tt>externT</tt> are of the same type, and
- where the internal sequence <tt>c1 c2</tt> corresponds to the
- external sequence <tt>c2 c1</tt>.
- </p>
- <p>It was generally agreed that <tt>basic_filebuf</tt> relies
- on this property: it was designed under the assumption that
- the external-to-internal mapping is N-to-1, and it is not clear
- that <tt>basic_filebuf</tt> is implementable without that
- restriction.
- </p>
- <p>
- The proposed resolution is expressed as a restriction on
- <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
- than a blanket restriction on all <tt>codecvt</tt> facets,
- because <tt>basic_filebuf</tt> is the only other part of the
- library that uses <tt>codecvt</tt>. If a user wants to define
- a <tt>codecvt</tt> facet that implements a more general N-to-M
- mapping, there is no reason to prohibit it, so long as the user
- does not expect <tt>basic_filebuf</tt> to be able to use it.
- </p>
-
-
-
-
-
-<hr>
-<h3><a name="78"></a>78. Typo: event_call_back</h3>
-<p><b>Section:</b> 27.4.2 [ios.base] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base">issues</a> in [ios.base].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>typo: event_call_back should be event_callback &nbsp; </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In the 27.4.2 [ios.base] synopsis change
-"event_call_back" to "event_callback". </p>
-
-
-
-
-<hr>
-<h3><a name="79"></a>79. Inconsistent declaration of polar()</h3>
-<p><b>Section:</b> 26.3.1 [complex.synopsis], 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.synopsis">issues</a> in [complex.synopsis].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 26.3.1 [complex.synopsis] polar is declared as follows:</p>
-<pre> template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
-
-<p>In 26.3.7 [complex.value.ops] it is declared as follows:</p>
-<pre> template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
-
-<p>Thus whether the second parameter is optional is not clear. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 26.3.1 [complex.synopsis] change:</p>
-<pre> template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>
-
-<p>to:</p>
-<pre> template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
-
-
-
-
-
-<hr>
-<h3><a name="80"></a>80. Global Operators of complex declared twice</h3>
-<p><b>Section:</b> 26.3.1 [complex.synopsis], 26.3.2 [complex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.synopsis">issues</a> in [complex.synopsis].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
-class complex. This redundancy should be removed.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Reduce redundancy according to the general style of the standard. </p>
-
-
-
-
-<hr>
-<h3><a name="83"></a>83. String::npos vs. string::max_size()</h3>
-<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#89">89</a></p>
-<p><b>Discussion:</b></p>
-<p>Many string member functions throw if size is getting or exceeding
-npos. However, I wonder why they don't throw if size is getting or
-exceeding max_size() instead of npos. May be npos is known at compile
-time, while max_size() is known at runtime. However, what happens if
-size exceeds max_size() but not npos, then? It seems the standard
-lacks some clarifications here.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>After 21.3 [basic.string] paragraph 4 ("The functions
-described in this clause...") add a new paragraph:</p>
-
-<blockquote>
- <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
- <tt> max_size()</tt> then
- the operation throws <tt>length_error</tt>.</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes length_error is the correct exception to throw.</p>
-
-
-
-
-<hr>
-<h3><a name="86"></a>86. String constructors don't describe exceptions</h3>
-<p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The constructor from a range:</p>
-
-<pre>template&lt;class InputIterator&gt;
- basic_string(InputIterator begin, InputIterator end,
- const Allocator&amp; a = Allocator());</pre>
-
-<p>lacks a throws clause. However, I would expect that it throws
-according to the other constructors if the numbers of characters in
-the range equals npos (or exceeds max_size(), see above). </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 21.3.1 [string.require], Strike throws paragraphs for
-constructors which say "Throws: length_error if n ==
-npos."</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Throws clauses for length_error if n == npos are no longer needed
-because they are subsumed by the general wording added by the
-resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
-
-
-
-
-<hr>
-<h3><a name="90"></a>90. Incorrect description of operator &gt;&gt; for strings</h3>
-<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The effect of operator &gt;&gt; for strings contain the following item:</p>
-
-<p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
-character c.</p>
-
-<p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 21.3.8.9 [string.io] paragraph 1 Effects clause replace:</p>
-
-<blockquote>
- <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
-</blockquote>
-
-<p>with:</p>
-
-<blockquote>
- <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="91"></a>91. Description of operator&gt;&gt; and getline() for string&lt;&gt; might cause endless loop</h3>
-<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Operator &gt;&gt; and getline() for strings read until eof()
-in the input stream is true. However, this might never happen, if the
-stream can't read anymore without reaching EOF. So shouldn't it be
-changed into that it reads until !good() ? </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 21.3.8.9 [string.io], paragraph 1, replace:</p>
-<blockquote><p>
-Effects: Begins by constructing a sentry object k as if k were
-constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
-bool( k) is true, it calls str.erase() and then extracts characters
-from is and appends them to str as if by calling str.append(1, c). If
-is.width() is greater than zero, the maximum number n of characters
-appended is is.width(); otherwise n is str.max_size(). Characters are
-extracted and appended until any of the following occurs:
-</p></blockquote>
-<p>with:</p>
-<blockquote><p>
-Effects: Behaves as a formatted input function (27.6.1.2.1
-[istream.formatted.reqmts]). After constructing a sentry object, if the
-sentry converts to true, calls str.erase() and then extracts
-characters from is and appends them to str as if by calling
-str.append(1,c). If is.width() is greater than zero, the maximum
-number n of characters appended is is.width(); otherwise n is
-str.max_size(). Characters are extracted and appended until any of the
-following occurs:
-</p></blockquote>
-
-<p>In 21.3.8.9 [string.io], paragraph 6, replace</p>
-<blockquote><p>
-Effects: Begins by constructing a sentry object k as if by typename
-basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
-it calls str.erase() and then extracts characters from is and appends
-them to str as if by calling str.append(1, c) until any of the
-following occurs:
-</p></blockquote>
-<p>with:</p>
-<blockquote><p>Effects: Behaves as an unformatted input function
-(27.6.1.3 [istream.unformatted]), except that it does not affect the
-value returned
-by subsequent calls to basic_istream&lt;&gt;::gcount(). After
-constructing a sentry object, if the sentry converts to true, calls
-str.erase() and then extracts characters from is and appends them to
-str as if by calling str.append(1,c) until any of the following
-occurs:
-</p></blockquote>
-
-<p><i>[Redmond: Made changes in proposed resolution. <tt>operator&gt;&gt;</tt>
-should be a formatted input function, not an unformatted input function.
-<tt>getline</tt> should not be required to set <tt>gcount</tt>, since
-there is no mechanism for <tt>gcount</tt> to be set except by one of
-<tt>basic_istream</tt>'s member functions.]</i></p>
-
-
-<p><i>[Curaao: Nico agrees with proposed resolution.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The real issue here is whether or not these string input functions
-get their characters from a streambuf, rather than by calling an
-istream's member functions, a streambuf signals failure either by
-returning eof or by throwing an exception; there are no other
-possibilities. The proposed resolution makes it clear that these two
-functions do get characters from a streambuf.</p>
-
-
-
-
-
-<hr>
-<h3><a name="92"></a>92. Incomplete Algorithm Requirements</h3>
-<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 1998-09-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The standard does not state, how often a function object is copied,
-called, or the order of calls inside an algorithm. This may lead to
-surprising/buggy behavior. Consider the following example: </p>
-
-<pre>class Nth { // function object that returns true for the nth element
- private:
- int nth; // element to return true for
- int count; // element counter
- public:
- Nth (int n) : nth(n), count(0) {
- }
- bool operator() (int) {
- return ++count == nth;
- }
-};
-....
-// remove third element
- list&lt;int&gt;::iterator pos;
- pos = remove_if(coll.begin(),coll.end(), // range
- Nth(3)), // remove criterion
- coll.erase(pos,coll.end()); </pre>
-
-<p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
-happens because the usual implementation of the algorithm copies the
-function object internally: </p>
-
-<pre>template &lt;class ForwIter, class Predicate&gt;
-ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
-{
- beg = find_if(beg, end, op);
- if (beg == end) {
- return beg;
- }
- else {
- ForwIter next = beg;
- return remove_copy_if(++next, end, beg, op);
- }
-} </pre>
-
-<p>The algorithm uses find_if() to find the first element that should
-be removed. However, it then uses a copy of the passed function object
-to process the resulting elements (if any). Here, Nth is used again
-and removes also the sixth element. This behavior compromises the
-advantage of function objects being able to have a state. Without any
-cost it could be avoided (just implement it directly instead of
-calling find_if()). </p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Add a new paragraph following 25 [algorithms] paragraph 8:</p>
-<blockquote><p>
-[Note: Unless otherwise specified, algorithms that take function
-objects as arguments are permitted to copy those function objects
-freely. Programmers for whom object identity is important should
-consider using a wrapper class that points to a noncopied
-implementation object, or some equivalent solution.]
-</p></blockquote>
-
-<p><i>[Dublin: Pete Becker felt that this may not be a defect,
-but rather something that programmers need to be educated about.
-There was discussion of adding wording to the effect that the number
-and order of calls to function objects, including predicates, not
-affect the behavior of the function object.]</i></p>
-
-
-<p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
-have a clear statement of "predicate" in the
-standard. People including me seemed to think "a function
-returning a Boolean value and being able to be called by an STL
-algorithm or be used as sorting criterion or ... is a
-predicate". But a predicate has more requirements: It should
-never change its behavior due to a call or being copied. IMHO we have
-to state this in the standard. If you like, see section 8.1.4 of my
-library book for a detailed discussion.]</i></p>
-
-
-<p><i>[Kona: Nico will provide wording to the effect that "unless
-otherwise specified, the number of copies of and calls to function
-objects by algorithms is unspecified".&nbsp; Consider placing in
-25 [algorithms] after paragraph 9.]</i></p>
-
-
-<p><i>[Santa Cruz: The standard doesn't currently guarantee that
- functions object won't be copied, and what isn't forbidden is
- allowed. It is believed (especially since implementations that were
- written in concert with the standard do make copies of function
- objects) that this was intentional. Thus, no normative change is
- needed. What we should put in is a non-normative note suggesting to
- programmers that if they want to guarantee the lack of copying they
- should use something like the <tt>ref</tt> wrapper.]</i></p>
-
-
-<p><i>[Oxford: Matt provided wording.]</i></p>
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="98"></a>98. Input iterator requirements are badly written</h3>
-<p><b>Section:</b> 24.1.1 [input.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.iterators">issues</a> in [input.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Table 72 in 24.1.1 [input.iterators] specifies semantics for
-<tt>*r++</tt> of:</p>
-
-<p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
-
-<p>There are two problems with this. First, the return type is
-specified to be "T", as opposed to something like "convertible to T".
-This is too specific: we want to allow *r++ to return an lvalue.</p>
-
-<p>Second, writing the semantics in terms of code misleadingly
-suggests that the effects *r++ should precisely replicate the behavior
-of this code, including side effects. (Does this mean that *r++
-should invoke the copy constructor exactly as many times as the sample
-code above would?) See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a> for a similar
-problem.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In Table 72 in 24.1.1 [input.iterators], change the return type
-for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This issue has two parts: the return type, and the number of times
- the copy constructor is invoked.</p>
-
-<p>The LWG believes the the first part is a real issue. It's
- inappropriate for the return type to be specified so much more
- precisely for *r++ than it is for *r. In particular, if r is of
- (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
- but <tt>int&amp;</tt>.</p>
-
-<p>The LWG does not believe that the number of times the copy
- constructor is invoked is a real issue. This can vary in any case,
- because of language rules on copy constructor elision. That's too
- much to read into these semantics clauses.</p>
-
-<p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since
- we're told (24.1/3) that forward iterators satisfy all the requirements
- of input iterators, we can't impose any requirements in the Input
- Iterator requirements table that forward iterators don't satisfy.</p>
-
-
-
-
-
-<hr>
-<h3><a name="103"></a>103. set::iterator is required to be modifiable, but this allows modification of keys</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Set::iterator is described as implementation-defined with a
-reference to the container requirement; the container requirement says
-that const_iterator is an iterator pointing to const T and iterator an
-iterator pointing to T.</p>
-
-<p>23.1.2 paragraph 2 implies that the keys should not be modified to
-break the ordering of elements. But that is not clearly
-specified. Especially considering that the current standard requires
-that iterator for associative containers be different from
-const_iterator. Set, for example, has the following: </p>
-
-<p><tt>typedef implementation defined iterator;<br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>
-
-<p>23.1 [container.requirements] actually requires that iterator type pointing
-to T (table 65). Disallowing user modification of keys by changing the
-standard to require an iterator for associative container to be the
-same as const_iterator would be overkill since that will unnecessarily
-significantly restrict the usage of associative container. A class to
-be used as elements of set, for example, can no longer be modified
-easily without either redesigning the class (using mutable on fields
-that have nothing to do with ordering), or using const_cast, which
-defeats requiring iterator to be const_iterator. The proposed solution
-goes in line with trusting user knows what he is doing. </p>
-
-<p><b>Other Options Evaluated:</b> </p>
-
-<p>Option A.&nbsp;&nbsp; In 23.1.4 [associative.reqmts], paragraph 2, after
-first sentence, and before "In addition,...", add one line:
-</p>
-
-<blockquote>
- <p>Modification of keys shall not change their strict weak ordering. </p>
-</blockquote>
-
-<p>Option B.&nbsp;Add three new sentences to 23.1.4 [associative.reqmts]:</p>
-
-<blockquote>
- <p>At the end of paragraph 5: "Keys in an associative container
- are immutable." At the end of paragraph 6: "For
- associative containers where the value type is the same as the key
- type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
- constant iterators. It is unspecified whether or not
- <tt>iterator</tt> and <tt>const_iterator</tt> are the same
- type."</p>
-</blockquote>
-
-<p>Option C.&nbsp;To 23.1.4 [associative.reqmts], paragraph 3, which
-currently reads:</p>
-
-<blockquote>
- <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
- comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
- container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
- == false &amp;&amp; comp(k2, k1) == false.</p>
-</blockquote>
-
-<p>&nbsp; add the following:</p>
-
-<blockquote>
- <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
- value whenever it is evaluated. [Note: If k2 is removed from the container and later
- reinserted, comp(k1, k2) must still return a consistent value but this value may be
- different than it was the first time k1 and k2 were in the same container. This is
- intended to allow usage like a string key that contains a filename, where comp compares
- file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
- reinserted, comp(k1, k2) must again return a consistent value but this value may be
- different than it was the previous time k2 was in the container.]</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add the following to 23.1.4 [associative.reqmts] at
-the indicated location:</p>
-
-<blockquote>
- <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
- calling comp(k1, k2) shall always return the same
- value."</p>
- <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
- <p>At the end of paragraph 6: "For associative containers where the value type is the
- same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
- iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
- are the same type."</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>Several arguments were advanced for and against allowing set elements to be
-mutable as long as the ordering was not effected. The argument which swayed the
-LWG was one of safety; if elements were mutable, there would be no compile-time
-way to detect of a simple user oversight which caused ordering to be
-modified. There was a report that this had actually happened in practice,
-and had been painful to diagnose. If users need to modify elements,
-it is possible to use mutable members or const_cast.</p>
-
-<p>Simply requiring that keys be immutable is not sufficient, because the comparison
-object may indirectly (via pointers) operate on values outside of the keys.</p>
-
-<p>
-The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
-to be different types to allow for potential future work in which some
-member functions might be overloaded between the two types. No such
-member functions exist now, and the LWG believes that user functionality
-will not be impaired by permitting the two types to be the same. A
-function that operates on both iterator types can be defined for
-<tt>const_iterator</tt> alone, and can rely on the automatic
-conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
-</p>
-
-<p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="106"></a>106. Numeric library private members are implementation defined</h3>
-<p><b>Section:</b> 26.5.5 [template.slice.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.slice.array">issues</a> in [template.slice.array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>This is the only place in the whole standard where the implementation has to document
-something private.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove the comment which says "// remainder implementation defined" from:
-</p>
-
-<ul>
- <li>26.5.5 [template.slice.array]</li>
- <li>26.5.7 [template.gslice.array]</li>
- <li>26.5.8 [template.mask.array]</li>
- <li>26.5.9 [template.indirect.array]</li>
-</ul>
-
-
-
-
-
-<hr>
-<h3><a name="108"></a>108. Lifetime of exception::what() return unspecified</h3>
-<p><b>Section:</b> 18.6.1 [type.info] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> AFNOR <b>Date:</b> 1998-10-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#type.info">issues</a> in [type.info].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
-exception::what() is left unspecified. This issue has implications
-with exception safety of exception handling: some exceptions should
-not throw bad_alloc.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add to 18.6.1 [type.info] paragraph 9 (exception::what notes
-clause) the sentence:</p>
-
-<blockquote>
- <p>The return value remains valid until the exception object from which it is obtained is
- destroyed or a non-const member function of the exception object is called.</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>If an exception object has non-const members, they may be used
-to set internal state that should affect the contents of the string
-returned by <tt>what()</tt>.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="109"></a>109. Missing binders for non-const sequence elements</h3>
-<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Bjarne Stroustrup <b>Date:</b> 1998-10-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>There are no versions of binders that apply to non-const elements
-of a sequence. This makes examples like for_each() using bind2nd() on
-page 521 of "The C++ Programming Language (3rd)"
-non-conforming. Suitable versions of the binders need to be added.</p>
-
-<p>Further discussion from Nico:</p>
-
-<p>What is probably meant here is shown in the following example:</p>
-
-<pre>class Elem {
- public:
- void print (int i) const { }
- void modify (int i) { }
-}; </pre>
-<pre>int main()
-{
- vector&lt;Elem&gt; coll(2);
- for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42)); // OK
- for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42)); // ERROR
-}</pre>
-
-<p>The error results from the fact that bind2nd() passes its first
-argument (the argument of the sequence) as constant reference. See the
-following typical implementation:</p>
-
-<blockquote>
- <pre>template &lt;class Operation&gt;
-class binder2nd
- : public unary_function&lt;typename Operation::first_argument_type,
- typename Operation::result_type&gt; {
-protected:
- Operation op;
- typename Operation::second_argument_type value;
-public:
- binder2nd(const Operation&amp; o,
- const typename Operation::second_argument_type&amp; v)
- : op(o), value(v) {} </pre>
- <pre> typename Operation::result_type
- operator()(const typename Operation::first_argument_type&amp; x) const {
- return op(x, value);
- }
-};</pre>
-</blockquote>
-
-<p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
-
-<blockquote>
- <pre>template &lt;class Operation&gt;
-class binder2nd
- : public unary_function&lt;typename Operation::first_argument_type,
- typename Operation::result_type&gt; {
-protected:
- Operation op;
- typename Operation::second_argument_type value;
-public:
- binder2nd(const Operation&amp; o,
- const typename Operation::second_argument_type&amp; v)
- : op(o), value(v) {} </pre>
- <pre> typename Operation::result_type
- operator()(const typename Operation::first_argument_type&amp; x) const {
- return op(x, value);
- }
- typename Operation::result_type
- operator()(typename Operation::first_argument_type&amp; x) const {
- return op(x, value);
- }
-};</pre>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p><b>Howard believes there is a flaw</b> in this resolution.
-See c++std-lib-9127. We may need to reopen this issue.</p>
-
-<p>In D.8 [depr.lib.binders] in the declaration of binder1st after:</p>
-<blockquote>
- <p><tt>typename Operation::result_type<br>
- &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
-</blockquote>
-<p>insert:</p>
-<blockquote>
- <p><tt>typename Operation::result_type<br>
- &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
-</blockquote>
-<p>In D.8 [depr.lib.binders] in the declaration of binder2nd after:</p>
-<blockquote>
- <p><tt>typename Operation::result_type<br>
- &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
-</blockquote>
-<p>insert:</p>
-<blockquote>
- <p><tt>typename Operation::result_type<br>
- &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
-</blockquote>
-
-<p><i>[Kona: The LWG discussed this at some length.It was agreed that
-this is a mistake in the design, but there was no consensus on whether
-it was a defect in the Standard. Straw vote: NAD - 5. Accept
-proposed resolution - 3. Leave open - 6.]</i></p>
-
-
-<p><i>[Copenhagen: It was generally agreed that this was a defect.
-Strap poll: NAD - 0. Accept proposed resolution - 10.
-Leave open - 1.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="110"></a>110. istreambuf_iterator::equal not const</h3>
-<p><b>Section:</b> 24.5.3 [istreambuf.iterator], 24.5.3.5 [istreambuf.iterator::equal] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 1998-10-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istreambuf.iterator">issues</a> in [istreambuf.iterator].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Member istreambuf_iterator&lt;&gt;::equal is not declared
-"const", yet 24.5.3.6 [istreambuf.iterator::op==] says that operator==,
-which is const, calls it. This is contradictory. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 24.5.3 [istreambuf.iterator] and also in 24.5.3.5 [istreambuf.iterator::equal],
-replace:</p>
-
-<blockquote>
- <pre>bool equal(istreambuf_iterator&amp; b);</pre>
-</blockquote>
-
-<p>with:</p>
-
-<blockquote>
- <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="112"></a>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3>
-<p><b>Section:</b> 24.5.4.1 [ostreambuf.iter.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-10-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
-constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
-reads "<i>s</i> is not null". However, <i>s</i> is a
-reference, and references can't be null. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 24.5.4.1 [ostreambuf.iter.cons]:</p>
-
-<p>Move the current paragraph 1, which reads "Requires: s is not
-null.", from the first constructor to the second constructor.</p>
-
-<p>Insert a new paragraph 1 Requires clause for the first constructor
-reading:</p>
-
-<blockquote>
- <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="114"></a>114. Placement forms example in error twice</h3>
-<p><b>Section:</b> 18.5.1.3 [new.delete.placement] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-10-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.placement">issues</a> in [new.delete.placement].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a></p>
-<p><b>Discussion:</b></p>
-<p>Section 18.5.1.3 contains the following example: </p>
-
-<pre>[Example: This can be useful for constructing an object at a known address:
- char place[sizeof(Something)];
- Something* p = new (place) Something();
- -end example]</pre>
-
-<p>First code line: "place" need not have any special alignment, and the
-following constructor could fail due to misaligned data.</p>
-
-<p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
-believes the () are correct.]</p>
-
-<p>Examples are not normative, but nevertheless should not show code that is invalid or
-likely to fail.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace the first line of code in the example in
-18.5.1.3 [new.delete.placement] with:
-</p>
-
-<blockquote>
- <pre>void* place = operator new(sizeof(Something));</pre>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="115"></a>115. Typo in strstream constructors</h3>
-<p><b>Section:</b> D.7.4.1 [depr.strstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 1998-11-02</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>D.7.4.1 strstream constructors paragraph 2 says: </p>
-
-<blockquote>
- <p>Effects: Constructs an object of class strstream, initializing the base class with
- iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
- <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
- elements. The constructor is strstreambuf(s, n, s). </p>
- <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
- elements that contains an NTBS whose first element is designated by s. The constructor is
- strstreambuf(s, n, s+std::strlen(s)).</p>
-</blockquote>
-
-<p>Notice the second condition is the same as the first. I think the second condition
-should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
-the append bit is set.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In D.7.3.1 [depr.ostrstream.cons] paragraph 2 and D.7.4.1 [depr.strstream.cons]
-paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
-and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>
-
-
-
-
-
-<hr>
-<h3><a name="117"></a>117. <tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3>
-<p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-11-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The <b>effects</b> clause for numeric inserters says that
-insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
-<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
-int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
-<tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
-delegated to <tt>num_put</tt>, and that insertion is performed as if
-through the following code fragment: </p>
-
-<pre>bool failed = use_facet&lt;
- num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
- &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>
-
-<p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
-overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
-long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
-void*</tt>. That is, the code fragment in the standard is incorrect
-(it is diagnosed as ambiguous at compile time) for the types
-<tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
-int</tt>, and <tt>float</tt>. </p>
-
-<p>We must either add new member functions to <tt>num_put</tt>, or
-else change the description in <tt>ostream</tt> so that it only calls
-functions that are actually there. I prefer the latter. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
-
-<blockquote>
-<p>
-The classes num_get&lt;&gt; and num_put&lt;&gt; handle locale-dependent numeric
-formatting and parsing. These inserter functions use the imbued
-locale value to perform numeric formatting. When val is of type bool,
-long, unsigned long, double, long double, or const void*, the
-formatting conversion occurs as if it performed the following code
-fragment:
-</p>
-
-<pre>bool failed = use_facet&lt;
- num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
- &gt;(getloc()).put(*this, *this, fill(), val). failed();
-</pre>
-
-<p>
-When val is of type short the formatting conversion occurs as if it
-performed the following code fragment:
-</p>
-
-<pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
-bool failed = use_facet&lt;
- num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
- &gt;(getloc()).put(*this, *this, fill(),
- baseflags == ios_base::oct || baseflags == ios_base::hex
- ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
- : static_cast&lt;long&gt;(val)). failed();
-</pre>
-
-<p>
-When val is of type int the formatting conversion occurs as if it performed
-the following code fragment:
-</p>
-
-<pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
-bool failed = use_facet&lt;
- num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
- &gt;(getloc()).put(*this, *this, fill(),
- baseflags == ios_base::oct || baseflags == ios_base::hex
- ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
- : static_cast&lt;long&gt;(val)). failed();
-</pre>
-
-<p>
-When val is of type unsigned short or unsigned int the formatting conversion
-occurs as if it performed the following code fragment:
-</p>
-
-<pre>bool failed = use_facet&lt;
- num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
- &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
-failed();
-</pre>
-
-<p>
-When val is of type float the formatting conversion occurs as if it
-performed the following code fragment:
-</p>
-
-<pre>bool failed = use_facet&lt;
- num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
- &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
-failed();
-</pre>
-
-</blockquote>
-
-<p><i>[post-Toronto: This differs from the previous proposed
-resolution; PJP provided the new wording. The differences are in
-signed short and int output.]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>The original proposed resolution was to cast int and short to long,
-unsigned int and unsigned short to unsigned long, and float to double,
-thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
-member functions. The current proposed resolution is more
-complicated, but gives more expected results for hex and octal output
-of signed short and signed int. (On a system with 16-bit short, for
-example, printing short(-1) in hex format should yield 0xffff.)</p>
-
-
-
-
-
-<hr>
-<h3><a name="118"></a>118. <tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3>
-<p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1998-11-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
-<tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
-<tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
-formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
-
-<pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
-iostate err = 0;
-use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val);
-setstate(err);</pre>
-
-<p>According to section 22.2.2.1.1 [facet.num.get.members], however,
-<tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
-<tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
-int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
-<tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
-<tt>void*</tt>. Comparing the lists from the two sections, we find
-that 27.6.1.2.2 is using a nonexistent function for types
-<tt>short</tt> and <tt>int</tt>. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.2.2 [istream.formatted.arithmetic] Arithmetic Extractors, remove the
-two lines (1st and 3rd) which read:</p>
-<blockquote>
- <pre>operator&gt;&gt;(short&amp; val);
-...
-operator&gt;&gt;(int&amp; val);</pre>
-</blockquote>
-
-<p>And add the following at the end of that section (27.6.1.2.2) :</p>
-
-<blockquote>
- <pre>operator&gt;&gt;(short&amp; val);</pre>
- <p>The conversion occurs as if performed by the following code fragment (using
- the same notation as for the preceding code fragment):</p>
- <pre> typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
- iostate err = 0;
- long lval;
- use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
- if (err == 0
- &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
- err = ios_base::failbit;
- setstate(err);</pre>
- <pre>operator&gt;&gt;(int&amp; val);</pre>
- <p>The conversion occurs as if performed by the following code fragment (using
- the same notation as for the preceding code fragment):</p>
- <pre> typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
- iostate err = 0;
- long lval;
- use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
- if (err == 0
- &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
- err = ios_base::failbit;
- setstate(err);</pre>
-</blockquote>
-
-<p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="119"></a>119. Should virtual functions be allowed to strengthen the exception specification?</h3>
-<p><b>Section:</b> 17.4.4.9 [res.on.exception.handling] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#res.on.exception.handling">issues</a> in [res.on.exception.handling].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Section 17.4.4.9 [res.on.exception.handling] states: </p>
-
-<p>"An implementation may strengthen the exception-specification
-for a function by removing listed exceptions." </p>
-
-<p>The problem is that if an implementation is allowed to do this for
-virtual functions, then a library user cannot write a class that
-portably derives from that class. </p>
-
-<p>For example, this would not compile if ios_base::failure::~failure
-had an empty exception specification: </p>
-
-<pre>#include &lt;ios&gt;
-#include &lt;string&gt;
-
-class D : public std::ios_base::failure {
-public:
- D(const std::string&amp;);
- ~D(); // error - exception specification must be compatible with
- // overridden virtual function ios_base::failure::~failure()
-};</pre>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change Section 17.4.4.9 [res.on.exception.handling] from:</p>
-
-<p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
-exception-specification for a function"</p>
-
-<p>to:</p>
-
-<p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
-exception-specification for a non-virtual function". </p>
-
-
-
-
-
-<hr>
-<h3><a name="120"></a>120. Can an implementor add specializations?</h3>
-<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>The original issue asked whether a library implementor could
-specialize standard library templates for built-in types. (This was
-an issue because users are permitted to explicitly instantiate
-standard library templates.)</p>
-
-<p>Specializations are no longer a problem, because of the resolution
-to core issue 259. Under the proposed resolution, it will be legal
-for a translation unit to contain both a specialization and an
-explicit instantiation of the same template, provided that the
-specialization comes first. In such a case, the explicit
-instantiation will be ignored. Further discussion of library issue
-120 assumes that the core 259 resolution will be adopted.</p>
-
-<p>However, as noted in lib-7047, one piece of this issue still
-remains: what happens if a standard library implementor explicitly
-instantiates a standard library templates? It's illegal for a program
-to contain two different explicit instantiations of the same template
-for the same type in two different translation units (ODR violation),
-and the core working group doesn't believe it is practical to relax
-that restriction.</p>
-
-<p>The issue, then, is: are users allowed to explicitly instantiate
-standard library templates for non-user defined types? The status quo
-answer is 'yes'. Changing it to 'no' would give library implementors
-more freedom.</p>
-
-<p>This is an issue because, for performance reasons, library
-implementors often need to explicitly instantiate standard library
-templates. (for example, std::basic_string&lt;char&gt;) Does giving
-users freedom to explicitly instantiate standard library templates for
-non-user defined types make it impossible or painfully difficult for
-library implementors to do this?</p>
-
-<p>John Spicer suggests, in lib-8957, that library implementors have a
-mechanism they can use for explicit instantiations that doesn't
-prevent users from performing their own explicit instantiations: put
-each explicit instantiation in its own object file. (Different
-solutions might be necessary for Unix DSOs or MS-Windows DLLs.) On
-some platforms, library implementors might not need to do anything
-special: the "undefined behavior" that results from having two
-different explicit instantiations might be harmless.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
- <p>Append to 17.4.3.2 [reserved.names] paragraph 1: </p>
- <blockquote><p>
- A program may explicitly instantiate any templates in the standard
- library only if the declaration depends on the name of a user-defined
- type of external linkage and the instantiation meets the standard library
- requirements for the original template.
- </p></blockquote>
-
-<p><i>[Kona: changed the wording from "a user-defined name" to "the name of
- a user-defined type"]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG considered another possible resolution:</p>
-<blockquote>
- <p>In light of the resolution to core issue 259, no normative changes
- in the library clauses are necessary. Add the following non-normative
- note to the end of 17.4.3.2 [reserved.names] paragraph 1:</p>
- <blockquote><p>
- [<i>Note:</i> A program may explicitly instantiate standard library
- templates, even when an explicit instantiation does not depend on
- a user-defined name. <i>--end note</i>]
- </p></blockquote>
-</blockquote>
-
-<p>The LWG rejected this because it was believed that it would make
- it unnecessarily difficult for library implementors to write
- high-quality implementations. A program may not include an
- explicit instantiation of the same template, for the same template
- arguments, in two different translation units. If users are
- allowed to provide explicit instantiations of Standard Library
- templates for built-in types, then library implementors aren't,
- at least not without nonportable tricks.</p>
-
-<p>The most serious problem is a class template that has writeable
- static member variables. Unfortunately, such class templates are
- important and, in existing Standard Library implementations, are
- often explicitly specialized by library implementors: locale facets,
- which have a writeable static member variable <tt>id</tt>. If a
- user's explicit instantiation collided with the implementations
- explicit instantiation, iostream initialization could cause locales
- to be constructed in an inconsistent state.</p>
-
-<p>One proposed implementation technique was for Standard Library
- implementors to provide explicit instantiations in separate object
- files, so that they would not be picked up by the linker when the
- user also provides an explicit instantiation. However, this
- technique only applies for Standard Library implementations that
- are packaged as static archives. Most Standard Library
- implementations nowadays are packaged as dynamic libraries, so this
- technique would not apply.</p>
-
-<p>The Committee is now considering standardization of dynamic
- linking. If there are such changes in the future, it may be
- appropriate to revisit this issue later.</p>
-
-
-
-
-
-<hr>
-<h3><a name="122"></a>122. streambuf/wstreambuf description should not say they are specializations</h3>
-<p><b>Section:</b> 27.5.2 [streambuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf">issues</a> in [streambuf].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Section 27.5.2 describes the streambuf classes this way: </p>
-
-<blockquote>
-
-<p>The class streambuf is a specialization of the template class basic_streambuf
-specialized for the type char. </p>
-
-<p>The class wstreambuf is a specialization of the template class basic_streambuf
-specialized for the type wchar_t. </p>
-
-</blockquote>
-
-<p>This implies that these classes must be template specializations, not typedefs. </p>
-
-<p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Remove 27.5.2 [streambuf] paragraphs 2 and 3 (the above two
-sentences). </p>
-
-
-<p><b>Rationale:</b></p>
-<p>The <tt>streambuf</tt> synopsis already has a declaration for the
-typedefs and that is sufficient. </p>
-
-
-
-
-
-<hr>
-<h3><a name="123"></a>123. Should valarray helper arrays fill functions be const?</h3>
-<p><b>Section:</b> 26.5.5.3 [slice.arr.fill], 26.5.7.3 [gslice.array.fill], 26.5.8.3 [mask.array.fill], 26.5.9.3 [indirect.array.fill] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>One of the operator= in the valarray helper arrays is const and one
-is not. For example, look at slice_array. This operator= in Section
-26.5.5.1 [slice.arr.assign] is const: </p>
-
-<p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
-
-<p>but this one in Section 26.5.5.3 [slice.arr.fill] is not: </p>
-
-<p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>
-
-<p>The description of the semantics for these two functions is similar. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>26.5.5 [template.slice.array] Template class slice_array</p>
-<blockquote>
-
- <p>In the class template definition for slice_array, replace the member
- function declaration</p>
- <pre> void operator=(const T&amp;);
- </pre>
- <p>with</p>
- <pre> void operator=(const T&amp;) const;
- </pre>
-</blockquote>
-
-<p>26.5.5.3 [slice.arr.fill] slice_array fill function</p>
-<blockquote>
-
- <p>Change the function declaration</p>
- <pre> void operator=(const T&amp;);
- </pre>
- <p>to</p>
- <pre> void operator=(const T&amp;) const;
- </pre>
-</blockquote>
-
-<p>26.5.7 [template.gslice.array] Template class gslice_array</p>
-<blockquote>
-
- <p>In the class template definition for gslice_array, replace the member
- function declaration</p>
- <pre> void operator=(const T&amp;);
- </pre>
- <p>with</p>
- <pre> void operator=(const T&amp;) const;
- </pre>
-</blockquote>
-
-<p>26.5.7.3 [gslice.array.fill] gslice_array fill function</p>
-<blockquote>
-
- <p>Change the function declaration</p>
- <pre> void operator=(const T&amp;);
- </pre>
- <p>to</p>
- <pre> void operator=(const T&amp;) const;
- </pre>
-</blockquote>
-
-<p>26.5.8 [template.mask.array] Template class mask_array</p>
-<blockquote>
-
- <p>In the class template definition for mask_array, replace the member
- function declaration</p>
- <pre> void operator=(const T&amp;);
- </pre>
- <p>with</p>
- <pre> void operator=(const T&amp;) const;
- </pre>
-</blockquote>
-
-<p>26.5.8.3 [mask.array.fill] mask_array fill function</p>
-<blockquote>
-
- <p>Change the function declaration</p>
- <pre> void operator=(const T&amp;);
- </pre>
- <p>to</p>
- <pre> void operator=(const T&amp;) const;
- </pre>
-</blockquote>
-
-<p>26.5.9 [template.indirect.array] Template class indirect_array</p>
-<blockquote>
-
- <p>In the class template definition for indirect_array, replace the member
- function declaration</p>
- <pre> void operator=(const T&amp;);
- </pre>
- <p>with</p>
- <pre> void operator=(const T&amp;) const;
- </pre>
-</blockquote>
-
-<p>26.5.9.3 [indirect.array.fill] indirect_array fill function</p>
-<blockquote>
-
- <p>Change the function declaration</p>
- <pre> void operator=(const T&amp;);
- </pre>
- <p>to</p>
- <pre> void operator=(const T&amp;) const;
- </pre>
-</blockquote>
-
-
-<p><i>[Redmond: Robert provided wording.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>There's no good reason for one version of operator= being const and
-another one not. Because of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, this now
-matters: these functions are now callable in more circumstances. In
-many existing implementations, both versions are already const.</p>
-
-
-
-
-
-<hr>
-<h3><a name="124"></a>124. ctype_byname&lt;charT&gt;::do_scan_is &amp; do_scan_not return type should be const charT*</h3>
-<p><b>Section:</b> 22.2.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.byname">issues</a> in [locale.ctype.byname].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In Section 22.2.1.2 [locale.ctype.byname]
-ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
-to return a const char* not a const charT*. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change Section 22.2.1.2 [locale.ctype.byname] <tt>do_scan_is()</tt> and
-<tt>do_scan_not()</tt> to return a <tt> const
-charT*</tt>. </p>
-
-
-
-
-
-<hr>
-<h3><a name="125"></a>125. valarray&lt;T&gt;::operator!() return type is inconsistent</h3>
-<p><b>Section:</b> 26.5.2 [template.valarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.valarray">issues</a> in [template.valarray].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In Section 26.5.2 [template.valarray] valarray&lt;T&gt;::operator!()
-is
-declared to return a valarray&lt;T&gt;, but in Section 26.5.2.5
-[valarray.unary] it is declared to return a valarray&lt;bool&gt;. The
-latter appears to be correct. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change in Section 26.5.2 [template.valarray] the declaration of
-<tt>operator!()</tt> so that the return type is
-<tt>valarray&lt;bool&gt;</tt>. </p>
-
-
-
-
-<hr>
-<h3><a name="126"></a>126. typos in Effects clause of ctype::do_narrow()</h3>
-<p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-12-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p><p>Typos in 22.2.1.1.2 need to be fixed.</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>In Section 22.2.1.1.2 [locale.ctype.virtuals] change: </p>
-
-<pre> do_widen(do_narrow(c),0) == c</pre>
-
-<p>to:</p>
-
-<pre> do_widen(do_narrow(c,0)) == c</pre>
-
-<p>and change:</p>
-
-<pre> (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
-
-<p>to:</p>
-
-<pre> (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
-
-
-
-
-
-<hr>
-<h3><a name="127"></a>127. auto_ptr&lt;&gt; conversion issues</h3>
-<p><b>Section:</b> D.9.1 [auto.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Greg Colvin <b>Date:</b> 1999-02-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#auto.ptr">issues</a> in [auto.ptr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>There are two problems with the current <tt>auto_ptr</tt> wording
-in the standard: </p>
-
-<p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
-because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
-<tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>. <i>Also submitted by
-Nathan Myers, with the same proposed resolution.</i></p>
-
-<p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
-<tt>auto_ptr_ref</tt> argument. </p>
-
-<p>I have discussed these problems with my proposal coauthor, Bill
-Gibbons, and with some compiler and library implementors, and we
-believe that these problems are not desired or desirable implications
-of the standard. </p>
-
-<p>25 Aug 1999: The proposed resolution now reflects changes suggested
-by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
-"assignment operator" to "public assignment
-operator", 2) changed effects to specify use of release(), 3)
-made the conversion to auto_ptr_ref const. </p>
-
-<p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
-states that the conversion from auto_ptr to auto_ptr_ref should
-be const. This is not acceptable, because it would allow
-initialization and assignment from _any_ const auto_ptr! It also
-introduces an implementation difficulty in writing this conversion
-function -- namely, somewhere along the line, a const_cast will be
-necessary to remove that const so that release() may be called. This
-may result in undefined behavior [7.1.5.1/4]. The conversion
-operator does not have to be const, because a non-const implicit
-object parameter may be bound to an rvalue [13.3.3.1.4/3]
-[13.3.1/5]. </p>
-
- <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
-
- <p>In 20.5.4 [meta.unary], paragraph 2, and 20.5.4.3 [meta.unary.prop],
- paragraph 2, make the conversion to auto_ptr_ref const:</p>
- <blockquote>
- <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
- </blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 20.5.4 [meta.unary], paragraph 2, move
-the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
-
-<p>In 20.5.4 [meta.unary], paragraph 2, add
-a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
-
-<blockquote>
- <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
-</blockquote>
-
-<p>Also add the assignment operator to 20.5.4.3 [meta.unary.prop]: </p>
-
-<blockquote>
- <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
-
- <p><b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
- p</tt> that <tt>r</tt> holds a reference to.<br>
- <b>Returns: </b><tt>*this</tt>.</p>
-
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="129"></a>129. Need error indication from seekp() and seekg()</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted], 27.6.2.5 [ostream.seeks] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-02-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Currently, the standard does not specify how seekg() and seekp()
-indicate failure. They are not required to set failbit, and they can't
-return an error indication because they must return *this, i.e. the
-stream. Hence, it is undefined what happens if they fail. And they
-<i>can</i> fail, for instance, when a file stream is disconnected from the
-underlying file (is_open()==false) or when a wide character file
-stream must perform a state-dependent code conversion, etc. </p>
-
-<p>The stream functions seekg() and seekp() should set failbit in the
-stream state in case of failure.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add to the Effects: clause of&nbsp; seekg() in
-27.6.1.3 [istream.unformatted] and to the Effects: clause of seekp() in
-27.6.2.5 [ostream.seeks]: </p>
-
-<blockquote>
- <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
- </p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>Setting failbit is the usual error reporting mechanism for streams</p>
-
-
-
-
-<hr>
-<h3><a name="130"></a>130. Return type of container::erase(iterator) differs for associative containers</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts], 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#451">451</a></p>
-<p><b>Discussion:</b></p>
-<p>Table 67 (23.1.1) says that container::erase(iterator) returns an
-iterator. Table 69 (23.1.2) says that in addition to this requirement,
-associative containers also say that container::erase(iterator)
-returns void. That's not an addition; it's a change to the
-requirements, which has the effect of making associative containers
-fail to meet the requirements for containers.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-In 23.1.4 [associative.reqmts], in Table 69 Associative container
-requirements, change the return type of <tt>a.erase(q)</tt> from
-<tt>void</tt> to <tt>iterator</tt>. Change the
-assertion/not/pre/post-condition from "erases the element pointed to
-by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
-Returns an iterator pointing to the element immediately following q
-prior to the element being erased. If no such element exists, a.end()
-is returned."
-</p>
-
-<p>
-In 23.1.4 [associative.reqmts], in Table 69 Associative container
-requirements, change the return type of <tt>a.erase(q1, q2)</tt>
-from <tt>void</tt> to <tt>iterator</tt>. Change the
-assertion/not/pre/post-condition from "erases the elements in the
-range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
-q2)</tt>. Returns q2."
-</p>
-
-<p>
-In 23.3.1 [map], in the <tt>map</tt> class synopsis; and
-in 23.3.2 [multimap], in the <tt>multimap</tt> class synopsis; and
-in 23.3.3 [set], in the <tt>set</tt> class synopsis; and
-in 23.3.4 [multiset], in the <tt>multiset</tt> class synopsis:
-change the signature of the first <tt>erase</tt> overload to
-</p>
-<pre> iterator erase(iterator position);
-</pre>
-<p>and change the signature of the third <tt>erase</tt> overload to</p>
-<pre> iterator erase(iterator first, iterator last);
-</pre>
-
-
-<p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
-
-
-<p><i>[Post-Kona: the LWG agrees the return type should be
-<tt>iterator</tt>, not <tt>void</tt>. (Alex Stepanov agrees too.)
-Matt provided wording.]</i></p>
-
-
-<p><i>[
- Sydney: the proposed wording went in the right direction, but it
- wasn't good enough. We want to return an iterator from the range form
- of erase as well as the single-iterator form. Also, the wording is
- slightly different from the wording we have for sequences; there's no
- good reason for having a difference. Matt provided new wording,
-(reflected above) which we will review at the next meeting.
-]</i></p>
-
-
-<p><i>[
-Redmond: formally voted into WP.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="132"></a>132. list::resize description uses random access iterators</h3>
-<p><b>Section:</b> 23.2.4.2 [list.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The description reads:</p>
-
-<p>-1- Effects:</p>
-
-<pre> if (sz &gt; size())
- insert(end(), sz-size(), c);
- else if (sz &lt; size())
- erase(begin()+sz, end());
- else
- ; // do nothing</pre>
-
-<p>Obviously list::resize should not be specified in terms of random access iterators.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 23.2.4.2 [list.capacity] paragraph 1 to:</p>
-
-<p>Effects:</p>
-
-<pre> if (sz &gt; size())
- insert(end(), sz-size(), c);
- else if (sz &lt; size())
- {
- iterator i = begin();
- advance(i, sz);
- erase(i, end());
- }</pre>
-
-<p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
-with David Abrahams. They had a discussion and believe there is
-no issue of exception safety with the proposed resolution.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="133"></a>133. map missing get_allocator()</h3>
-<p><b>Section:</b> 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map">issues</a> in [map].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p><p>The title says it all.</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>Insert in 23.3.1 [map], paragraph 2,
-after operator= in the map declaration:</p>
-
-<pre> allocator_type get_allocator() const;</pre>
-
-
-
-
-<hr>
-<h3><a name="134"></a>134. vector constructors over specified</h3>
-<p><b>Section:</b> 23.2.6.1 [vector.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The complexity description says: "It does at most 2N calls to the copy constructor
-of T and logN reallocations if they are just input iterators ...".</p>
-
-<p>This appears to be overly restrictive, dictating the precise memory/performance
-tradeoff for the implementor.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 23.2.6.1 [vector.cons], paragraph 1 to:</p>
-
-<p>-1- Complexity: The constructor template &lt;class
-InputIterator&gt; vector(InputIterator first, InputIterator last)
-makes only N calls to the copy constructor of T (where N is the
-distance between first and last) and no reallocations if iterators
-first and last are of forward, bidirectional, or random access
-categories. It makes order N calls to the copy constructor of T and
-order logN reallocations if they are just input iterators.
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>"at most 2N calls" is correct only if the growth factor
-is greater than or equal to 2.
-</p>
-
-
-
-
-<hr>
-<h3><a name="136"></a>136. seekp, seekg setting wrong streams?</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-03-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>I may be misunderstanding the intent, but should not seekg set only
-the input stream and seekp set only the output stream? The description
-seems to say that each should set both input and output streams. If
-that's really the intent, I withdraw this proposal.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In section 27.6.1.3 change:</p>
-
-<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
-Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
-
-<p>To:</p>
-
-<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
-Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>
-
-<p>In section 27.6.1.3 change:</p>
-
-<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
-Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
-
-<p>To:</p>
-
-<pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
-Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>
-
-<p>In section 27.6.2.4, paragraph 2 change:</p>
-
-<pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
-
-<p>To:</p>
-
-<pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>
-
-<p>In section 27.6.2.4, paragraph 4 change:</p>
-
-<pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
-
-<p>To:</p>
-
-<pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>
-
-<p><i>[Dublin: Dietmar Khl thinks this is probably correct, but would
-like the opinion of more iostream experts before taking action.]</i></p>
-
-
-<p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
-incorrect, his implementation already implements the Proposed
-Resolution.]</i></p>
-
-
-<p><i>[Post-Tokyo: Matt Austern comments:<br>
-Is it a problem with basic_istream and basic_ostream, or is it a problem
-with basic_stringbuf?
-We could resolve the issue either by changing basic_istream and
-basic_ostream, or by changing basic_stringbuf. I prefer the latter
-change (or maybe both changes): I don't see any reason for the standard to
-require that std::stringbuf s(std::string("foo"), std::ios_base::in);
-s.pubseekoff(0, std::ios_base::beg); must fail.<br>
-This requirement is a bit weird. There's no similar requirement
-for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
-basic_filebuf&lt;&gt;::seekpos.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="137"></a>137. Do use_facet and has_facet look in the global locale?</h3>
-<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-03-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Section 22.1.1 [locale] says:</p>
-
-<p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
-chooses a facet, making available all members of the named type. If
-Facet is not present in a locale (or, failing that, in the global
-locale), it throws the standard exception bad_cast. A C++ program can
-check if a locale implements a particular facet with the template
-function has_facet&lt;Facet&gt;(). </p>
-
-<p>This contradicts the specification given in section
-22.1.2 [locale.global.templates]:
-<br><br>
-template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
-locale&amp;&nbsp; loc); <br>
-<br>
--1- Get a reference to a facet of a locale. <br>
--2- Returns: a reference to the corresponding facet of loc, if present. <br>
--3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
--4- Notes: The reference returned remains valid at least as long as any copy of loc exists
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Remove the phrase "(or, failing that, in the global locale)"
-from section 22.1.1. </p>
-
-
-<p><b>Rationale:</b></p>
-<p>Needed for consistency with the way locales are handled elsewhere
-in the standard.</p>
-
-
-
-
-<hr>
-<h3><a name="139"></a>139. Optional sequence operation table description unclear</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-03-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The sentence introducing the Optional sequence operation table
-(23.1.1 paragraph 12) has two problems:</p>
-
-<p>A. It says ``The operations in table 68 are provided only for the containers for which
-they take constant time.''<br>
-<br>
-That could be interpreted in two ways, one of them being ``Even though table 68 shows
-particular operations as being provided, implementations are free to omit them if they
-cannot implement them in constant time.''<br>
-<br>
-B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
-with:</p>
-
-<blockquote>
- <p>Table 68 lists sequence operations that are provided for some types of sequential
- containers but not others. An implementation shall provide these operations for all
- container types shown in the ``container'' column, and shall implement them so as to take
- amortized constant time.</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="141"></a>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3>
-<p><b>Section:</b> 21.3.6.4 [string::insert], 21.3.6.6 [string::replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Arch Robison <b>Date:</b> 1999-04-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::insert">issues</a> in [string::insert].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
-say:<br>
-<br>
-&#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt></p>
-
-<p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
-
-<p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
-proposed resolution.]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
-<br>
-&#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
-<br>
-</tt>to:<br>
-<tt><br>
-</tt>&#8212; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>
-
-
-
-
-<hr>
-<h3><a name="142"></a>142. lexicographical_compare complexity wrong</h3>
-<p><b>Section:</b> 25.3.8 [alg.lex.comparison] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-06-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The lexicographical_compare complexity is specified as:<br>
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
-applications of the corresponding comparison."<br>
-<br>
-The best I can do is twice that expensive.</p>
-
-<p>Nicolai Josuttis comments in lib-6862: You mean, to check for
-equality you have to check both &lt; and &gt;? Yes, IMO you are
-right! (and Matt states this complexity in his book)</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 25.3.8 [alg.lex.comparison] complexity to:</p>
- <blockquote><p>
- At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
- applications of the corresponding comparison.
- </p></blockquote>
-
-<p>Change the example at the end of paragraph 3 to read:</p>
- <blockquote><p>
- [Example:<br>
- <br>
- &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
- ++first1, ++first2) {<br>
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
- &nbsp;&nbsp;&nbsp; }<br>
- &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
- &nbsp;&nbsp;&nbsp;<br>
- --end example]
- </p></blockquote>
-
-
-
-
-<hr>
-<h3><a name="144"></a>144. Deque constructor complexity wrong </h3>
-<p><b>Section:</b> 23.2.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Herb Sutter <b>Date:</b> 1999-05-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.cons">issues</a> in [deque.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 23.2.2.1 [deque.cons] paragraph 6, the deque ctor that takes an iterator range appears
-to have complexity requirements which are incorrect, and which contradict the
-complexity requirements for insert(). I suspect that the text in question,
-below, was taken from vector:</p>
-<blockquote>
- <p>Complexity: If the iterators first and last are forward iterators,
- bidirectional iterators, or random access iterators the constructor makes only
- N calls to the copy constructor, and performs no reallocations, where N is
- last - first.</p>
-</blockquote>
-<p>The word "reallocations" does not really apply to deque. Further,
-all of the following appears to be spurious:</p>
-<blockquote>
- <p>It makes at most 2N calls to the copy constructor of T and log N
- reallocations if they are input iterators.1)</p>
- <p>1) The complexity is greater in the case of input iterators because each
- element must be added individually: it is impossible to determine the distance
- between first abd last before doing the copying.</p>
-</blockquote>
-<p>This makes perfect sense for vector, but not for deque. Why should deque gain
-an efficiency advantage from knowing in advance the number of elements to
-insert?</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 23.2.2.1 [deque.cons] paragraph 6, replace the Complexity description, including the
-footnote, with the following text (which also corrects the "abd"
-typo):</p>
-<blockquote>
- <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="146"></a>146. complex&lt;T&gt; Inserter and Extractor need sentries</h3>
-<p><b>Section:</b> 26.3.6 [complex.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-05-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.ops">issues</a> in [complex.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The extractor for complex numbers is specified as:&nbsp;</p>
-
-<blockquote>
-
-<p> template&lt;class T, class charT, class traits&gt;&nbsp;<br>
- basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
- operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, complex&lt;T&gt;&amp; x);<br>
-&nbsp;<br>
-Effects: Extracts a complex number x of the form: u, (u), or (u,v),
-where u is the real part and v is the imaginary part
-(lib.istream.formatted).&nbsp;<br>
-Requires: The input values be convertible to T. If bad input is
-encountered, calls is.setstate(ios::failbit) (which may throw
-ios::failure (lib.iostate.flags).&nbsp;<br>
-Returns: is .</p>
-
-</blockquote>
-<p>Is it intended that the extractor for complex numbers does not skip
-whitespace, unlike all other extractors in the standard library do?
-Shouldn't a sentry be used?&nbsp;<br>
-<br>
-The inserter for complex numbers is specified as:</p>
-
-<blockquote>
-
-<p> template&lt;class T, class charT, class traits&gt;&nbsp;<br>
- basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
- operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x);<br>
-<br>
-Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
-<br>
- template&lt;class T, class charT, class traits&gt;&nbsp;<br>
- basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
- operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x)&nbsp;<br>
- {&nbsp;<br>
- basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
- s.flags(o.flags());&nbsp;<br>
- s.imbue(o.getloc());&nbsp;<br>
- s.precision(o.precision());&nbsp;<br>
- s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
- return o &lt;&lt; s.str();&nbsp;<br>
- }</p>
-
-</blockquote>
-
-<p>Is it intended that the inserter for complex numbers ignores the
-field width and does not do any padding? If, with the suggested
-implementation above, the field width were set in the stream then the
-opening parentheses would be adjusted, but the rest not, because the
-field width is reset to zero after each insertion.</p>
-
-<p>I think that both operations should use sentries, for sake of
-consistency with the other inserters and extractors in the
-library. Regarding the issue of padding in the inserter, I don't know
-what the intent was.&nbsp;</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>After 26.3.6 [complex.ops] paragraph 14 (operator&gt;&gt;), add a
-Notes clause:</p>
-
-<blockquote>
-
-<p>Notes: This extraction is performed as a series of simpler
-extractions. Therefore, the skipping of whitespace is specified to be the
-same for each of the simpler extractions.</p>
-
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>For extractors, the note is added to make it clear that skipping whitespace
-follows an "all-or-none" rule.</p>
-
-<p>For inserters, the LWG believes there is no defect; the standard is correct
-as written.</p>
-
-
-
-
-<hr>
-<h3><a name="147"></a>147. Library Intro refers to global functions that aren't global</h3>
-<p><b>Section:</b> 17.4.4.3 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 1999-06-04</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#global.functions">issues</a> in [global.functions].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The library had many global functions until 17.4.1.1 [lib.contents]
-paragraph 2 was added: </p>
-
-<blockquote>
-
-<p>All library entities except macros, operator new and operator
-delete are defined within the namespace std or namespaces nested
-within namespace std. </p>
-
-</blockquote>
-
-<p>It appears "global function" was never updated in the following: </p>
-
-<blockquote>
-
-<p>17.4.4.3 - Global functions [lib.global.functions]<br>
-<br>
--1- It is unspecified whether any global functions in the C++ Standard
-Library are defined as inline (dcl.fct.spec).<br>
-<br>
--2- A call to a global function signature described in Clauses
-lib.language.support through lib.input.output behaves the same as if
-the implementation declares no additional global function
-signatures.*<br>
-<br>
- [Footnote: A valid C++ program always calls the expected library
- global function. An implementation may also define additional
- global functions that would otherwise not be called by a valid C++
- program. --- end footnote]<br>
-<br>
--3- A global function cannot be declared by the implementation as
-taking additional default arguments.&nbsp;<br>
-<br>
-17.4.4.4 - Member functions [lib.member.functions]<br>
-<br>
--2- An implementation can declare additional non-virtual member
-function signatures within a class: </p>
-
- <blockquote>
-
-<p>-- by adding arguments with default values to a member function
-signature; The same latitude does not extend to the implementation of
-virtual or global functions, however. </p>
-
- </blockquote>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p> Change "global" to "global or non-member" in:</p>
-<blockquote>
- <p>17.4.4.3 [lib.global.functions] section title,<br>
- 17.4.4.3 [lib.global.functions] para 1,<br>
- 17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
- places in the footnote,<br>
- 17.4.4.3 [lib.global.functions] para 3,<br>
- 17.4.4.4 [lib.member.functions] para 2</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Because operator new and delete are global, the proposed resolution
-was changed from "non-member" to "global or non-member.
-</p>
-
-
-
-
-<hr>
-<h3><a name="148"></a>148. Functions in the example facet BoolNames should be const</h3>
-<p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Jeremy Siek <b>Date:</b> 1999-06-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 22.2.8 [facets.examples] paragraph 13, the do_truename() and
-do_falsename() functions in the example facet BoolNames should be
-const. The functions they are overriding in
-numpunct_byname&lt;char&gt; are const. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.8 [facets.examples] paragraph 13, insert "const" in
-two places:</p>
-<blockquote>
- <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
- string do_falsename() const { return "Mais Non!"; }</tt></p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="150"></a>150. Find_first_of says integer instead of iterator </h3>
-<p><b>Section:</b> 25.1.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt McClure <b>Date:</b> 1999-06-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 25.1.7 [alg.find.first.of] paragraph 2 from:</p>
-
-<blockquote>
-<p>Returns: The first iterator i in the range [first1, last1) such
-that for some integer j in the range [first2, last2) ...</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-<p>Returns: The first iterator i in the range [first1, last1) such
-that for some iterator j in the range [first2, last2) ...</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="151"></a>151. Can't currently clear() empty container</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Ed Brey <b>Date:</b> 1999-06-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>For both sequences and associative containers, a.clear() has the
-semantics of erase(a.begin(),a.end()), which is undefined for an empty
-container since erase(q1,q2) requires that q1 be dereferenceable
-(23.1.1,3 and 23.1.2,7). When the container is empty, a.begin() is
-not dereferenceable.<br>
-<br>
-The requirement that q1 be unconditionally dereferenceable causes many
-operations to be intuitively undefined, of which clearing an empty
-container is probably the most dire.<br>
-<br>
-Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
-q2) is required to be a valid range, stating that q1 and q2 must be
-iterators or certain kinds of iterators is unnecessary.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 23.1.1, paragraph 3, change:</p>
-<blockquote>
- <p>p and q2 denote valid iterators to a, q and q1 denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range
- in a</p>
-</blockquote>
-<p>In 23.1.2, paragraph 7, change:</p>
-<blockquote>
- <p>p and q2 are valid iterators to a, q and q1 are valid dereferenceable
- iterators to a, [q1, q2) is a valid range</p>
-</blockquote>
-<p>to</p>
-<blockquote>
- <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
- into a</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="152"></a>152. Typo in <tt>scan_is()</tt> semantics</h3>
-<p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
-because there is no function <tt>is()</tt> which only takes a character as
-argument. Also, in the effects clause (paragraph 3), the semantic is also kept
-vague.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.1.1.2 [locale.ctype.virtuals] paragraphs 4 and 6, change the returns
-clause from:</p>
-<blockquote>
- <p>"... such that <tt>is(*p)</tt>
-would..."</p>
-</blockquote>
-<p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
- would...."</p>
-
-
-
-
-
-<hr>
-<h3><a name="153"></a>153. Typo in <tt>narrow()</tt> semantics</h3>
-<p><b>Section:</b> 22.2.1.3.2 [facet.ctype.char.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.ctype.char.members">issues</a> in [facet.ctype.char.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a></p>
-<p><b>Discussion:</b></p>
-<p>The description of the array version of <tt>narrow()</tt> (in
-paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
-takes only three arguments because in addition to the range a default
-character is needed.</p>
-
-<p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
-two signatures followed by a <b>Returns</b> clause that only addresses
-one of them.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the returns clause in 22.2.1.3.2 [facet.ctype.char.members]
-paragraph 10 from:</p>
-<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
-
-<p>to:</p>
-<p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
-respectively.</p>
-
-<p>Change 22.2.1.3.2 [facet.ctype.char.members] paragraph 10 and 11 from:</p>
-<pre> char narrow(char c, char /*dfault*/) const;
- const char* narrow(const char* low, const char* high,
- char /*dfault*/, char* to) const;</pre>
-<pre> Returns: do_narrow(low, high, to).</pre>
-<p>to:</p>
-<pre> char narrow(char c, char dfault) const;
- const char* narrow(const char* low, const char* high,
- char dfault, char* to) const;</pre>
-<pre> Returns: do_narrow(c, dfault) or
- do_narrow(low, high, dfault, to), respectively.</pre>
-
-<p><i>[Kona: 1) the problem occurs in additional places, 2) a user
-defined version could be different.]</i></p>
-
-
-<p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
-the LWG. He could find no other places the problem occurred. He
-asks for clarification of the Kona "a user defined
-version..." comment above. Perhaps it was a circuitous way of
-saying "dfault" needed to be uncommented?]</i></p>
-
-
-<p><i>[Post-Toronto: the issues list maintainer has merged in the
-proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
-same paragraphs.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="154"></a>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt></h3>
-<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The table in paragraph 7 for the length modifier does not list the length
-modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
-standard asks the implementation to do undefined things when using <tt>scanf()</tt>
-(the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
-is actually a problem I found quite often in production code, too).</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.1.2 [facet.num.get.virtuals], paragraph 7, add a row in the Length
-Modifier table to say that for <tt>double</tt> a length modifier
-<tt>l</tt> is to be used.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The standard makes an embarrassing beginner's mistake.</p>
-
-
-
-
-<hr>
-<h3><a name="155"></a>155. Typo in naming the class defining the class <tt>Init</tt></h3>
-<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>There are conflicting statements about where the class
-<tt>Init</tt> is defined. According to 27.3 [iostream.objects] paragraph 2
-it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 [ios.base] it is defined as <tt>ios_base::Init</tt>.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 27.3 [iostream.objects] paragraph 2 from
-"<tt>basic_ios::Init"</tt> to
-"<tt>ios_base::Init"</tt>.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Although not strictly wrong, the standard was misleading enough to warrant
-the change.</p>
-
-
-
-
-<hr>
-<h3><a name="156"></a>156. Typo in <tt>imbue()</tt> description</h3>
-<p><b>Section:</b> 27.4.2.3 [ios.base.locales] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios.base.locales">issues</a> in [ios.base.locales].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>There is a small discrepancy between the declarations of
-<tt>imbue()</tt>: in 27.4.2 [ios.base] the argument is passed as
-<tt>locale const&amp;</tt> (correct), in 27.4.2.3 [ios.base.locales] it
-is passed as <tt>locale const</tt> (wrong).</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.4.2.3 [ios.base.locales] change the <tt>imbue</tt> argument
-from "<tt>locale const" to "locale
-const&amp;".</tt></p>
-
-
-
-
-<hr>
-<h3><a name="158"></a>158. Underspecified semantics for <tt>setbuf()</tt></h3>
-<p><b>Section:</b> 27.5.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.virt.buffer">issues</a> in [streambuf.virt.buffer].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The default behavior of <tt>setbuf()</tt> is described only for the
-situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
-namely to do nothing. What has to be done in other situations&nbsp;
-is not described although there is actually only one reasonable
-approach, namely to do nothing, too.</p>
-
-<p>Since changing the buffer would almost certainly mess up most
-buffer management of derived classes unless these classes do it
-themselves, the default behavior of <tt>setbuf()</tt> should always be
-to do nothing.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 27.5.2.4.2 [streambuf.virt.buffer], paragraph 3, Default behavior,
-to: "Default behavior: Does nothing. Returns this."</p>
-
-
-
-
-<hr>
-<h3><a name="159"></a>159. Strange use of <tt>underflow()</tt></h3>
-<p><b>Section:</b> 27.5.2.4.3 [streambuf.virt.get] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The description of the meaning of the result of
-<tt>showmanyc()</tt> seems to be rather strange: It uses calls to
-<tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
-this function only reads the current character but does not extract
-it, <tt>uflow()</tt> would extract the current character. This should
-be fixed to use <tt>sbumpc()</tt> instead.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 27.5.2.4.3 [streambuf.virt.get] paragraph 1,
-<tt>showmanyc()</tt>returns clause, by replacing the word
-"supplied" with the words "extracted from the
-stream".</p>
-
-
-
-
-<hr>
-<h3><a name="160"></a>160. Typo: Use of non-existing function <tt>exception()</tt></h3>
-<p><b>Section:</b> 27.6.1.1 [istream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream">issues</a> in [istream].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The paragraph 4 refers to the function <tt>exception()</tt> which
-is not defined. Probably, the referred function is
-<tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.1 [istream], 27.6.1.3 [istream.unformatted], paragraph 1,
-27.6.2.1 [ostream], paragraph 3, and 27.6.2.6.1 [ostream.formatted.reqmts],
-paragraph 1, change "<tt>exception()" to
-"exceptions()"</tt>.</p>
-
-<p><i>[Note to Editor: "exceptions" with an "s"
-is the correct spelling.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="161"></a>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt></h3>
-<p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The note in the second paragraph pretends that the first argument
-is an object of type <tt>istream_iterator</tt>. This is wrong: It is
-an object of type <tt>istreambuf_iterator</tt>.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 27.6.1.2.2 [istream.formatted.arithmetic] from:</p>
-<blockquote>
- <p>The first argument provides an object of the istream_iterator class...</p>
-</blockquote>
-<p>to</p>
-<blockquote>
- <p>The first argument provides an object of the istreambuf_iterator class...</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="164"></a>164. do_put() has apparently unused fill argument</h3>
-<p><b>Section:</b> 22.2.5.3.2 [locale.time.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 1999-07-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 22.2.5.3.2 [locale.time.put.virtuals] the do_put() function is specified
-as taking a fill character as an argument, but the description of the
-function does not say whether the character is used at all and, if so,
-in which way. The same holds for any format control parameters that
-are accessible through the ios_base&amp; argument, such as the
-adjustment or the field width. Is strftime() supposed to use the fill
-character in any way? In any case, the specification of
-time_put.do_put() looks inconsistent to me.<br> <br> Is the
-signature of do_put() wrong, or is the effects clause incomplete?</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add the following note after 22.2.5.3.2 [locale.time.put.virtuals]
-paragraph 2:</p>
-<blockquote>
- <p> [Note: the <tt>fill</tt> argument may be used in the implementation-defined formats, or by derivations. A space character is a reasonable default
- for this argument. --end Note]</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG felt that while the normative text was correct,
-users need some guidance on what to pass for the <tt>fill</tt>
-argument since the standard doesn't say how it's used.</p>
-
-
-
-
-<hr>
-<h3><a name="165"></a>165. <tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3>
-<p><b>Section:</b> 27.6.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream">issues</a> in [ostream].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
-functions falling into one of the groups "formatted output functions"
-and "unformatted output functions" calls any stream buffer function
-which might call a virtual function other than <tt>overflow()</tt>. Basically
-this is fine but this implies that <tt>sputn()</tt> (this function would call
-the virtual function <tt>xsputn()</tt>) is never called by any of the standard
-output functions. Is this really intended? At minimum it would be convenient to
-call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
-is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
-with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
-and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
-under "unformatted output functions").</p>
-<p>In addition, I guess that the sentence starting with "They may use other
-public members of <tt>basic_ostream</tt> ..." probably was intended to
-start with "They may use other public members of <tt>basic_streamuf</tt>..."
-although the problem with the virtual members exists in both cases.</p>
-<p>I see two obvious resolutions:</p>
-<ol>
- <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
- called by any ostream member and that this is intended.</li>
- <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
- Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
-</ol>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
-<blockquote>
- <p>They may use other public members of basic_ostream except that they do not
- invoke any virtual members of rdbuf() except overflow().</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>They may use other public members of basic_ostream except that they shall
- not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
- sync().</p>
-</blockquote>
-
-<p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
-PJP why the standard is written this way.]</i></p>
-
-
-<p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
-LWG. He comments: The rules can be made a little bit more specific if
-necessary be explicitly spelling out what virtuals are allowed to be
-called from what functions and eg to state specifically that flush()
-is allowed to call sync() while other functions are not.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="167"></a>167. Improper use of <tt>traits_type::length()</tt></h3>
-<p><b>Section:</b> 27.6.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.character">issues</a> in [ostream.inserters.character].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Paragraph 4 states that the length is determined using
-<tt>traits::length(s)</tt>. Unfortunately, this function is not
-defined for example if the character type is <tt>wchar_t</tt> and the
-type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
-the character type is <tt>char</tt> and the type of <tt>s</tt> is
-either <tt>signed char const*</tt> or <tt>unsigned char
-const*</tt>.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 27.6.2.6.4 [ostream.inserters.character] paragraph 4 from:</p>
-<blockquote>
- <p>Effects: Behaves like an formatted inserter (as described in
- lib.ostream.formatted.reqmts) of out. After a sentry object is
- constructed it inserts characters. The number of characters starting
- at s to be inserted is traits::length(s). Padding is determined as
- described in lib.facet.num.put.virtuals. The traits::length(s)
- characters starting at s are widened using out.widen
- (lib.basic.ios.members). The widened characters and any required
- padding are inserted into out. Calls width(0).</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>Effects: Behaves like a formatted inserter (as described in
- lib.ostream.formatted.reqmts) of out. After a sentry object is
- constructed it inserts <i>n</i> characters starting at <i>s</i>,
- where <i>n</i> is the number that would be computed as if by:</p>
- <ul>
- <li>traits::length(s) for the overload where the first argument is of
- type basic_ostream&lt;charT, traits&gt;&amp; and the second is
- of type const charT*, and also for the overload where the first
- argument is of type basic_ostream&lt;char, traits&gt;&amp; and
- the second is of type const char*.</li>
- <li>std::char_traits&lt;char&gt;::length(s)
- for the overload where the first argument is of type
- basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
- const char*.</li>
- <li>traits::length(reinterpret_cast&lt;const char*&gt;(s))
- for the other two overloads.</li>
- </ul>
- <p>Padding is determined as described in
- lib.facet.num.put.virtuals. The <i>n</i> characters starting at
- <i>s</i> are widened using out.widen (lib.basic.ios.members). The
- widened characters and any required padding are inserted into
- out. Calls width(0).</p>
-</blockquote>
-
-<p><i>[Santa Cruz: Matt supplied new wording]</i></p>
-
-
-<p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
- number that would be computed as if by"]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>We have five separate cases. In two of them we can use the
-user-supplied traits class without any fuss. In the other three we
-try to use something as close to that user-supplied class as possible.
-In two cases we've got a traits class that's appropriate for
-char and what we've got is a const signed char* or a const
-unsigned char*; that's close enough so we can just use a reinterpret
-cast, and continue to use the user-supplied traits class. Finally,
-there's one case where we just have to give up: where we've got a
-traits class for some arbitrary charT type, and we somehow have to
-deal with a const char*. There's nothing better to do but fall back
-to char_traits&lt;char&gt;</p>
-
-
-
-
-
-<hr>
-<h3><a name="168"></a>168. Typo: formatted vs. unformatted</h3>
-<p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The first paragraph begins with a descriptions what has to be done
-in <i>formatted</i> output functions. Probably this is a typo and the
-paragraph really want to describe unformatted output functions...</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.6.2.7 [ostream.unformatted] paragraph 1, the first and last
-sentences, change the word "formatted" to
-"unformatted":</p>
-<blockquote>
- <p>"Each <b>unformatted </b> output function begins ..."<br>
- "... value specified for the <b>unformatted </b> output
- function."</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="169"></a>169. Bad efficiency of <tt>overflow()</tt> mandated</h3>
-<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Paragraph 8, Notes, of this section seems to mandate an extremely
-inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
-especially in view of the restriction that <tt>basic_ostream</tt>
-member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 [ostream]): For each character to be inserted, a new buffer
-is to be created.</p>
-<p>Of course, the resolution below requires some handling of
-simultaneous input and output since it is no longer possible to update
-<tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
-solution is to handle this in <tt>underflow()</tt>.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.7.1.4 [stringbuf.virtuals] paragraph 8, Notes, insert the words
-"at least" as in the following:</p>
-<blockquote>
- <p>To make a write position available, the function reallocates (or initially
- allocates) an array object with a sufficient number of elements to hold the
- current array object (if any), plus <b>at least</b> one additional write
- position.</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="170"></a>170. Inconsistent definition of <tt>traits_type</tt></h3>
-<p><b>Section:</b> 27.7.4 [stringstream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The classes <tt>basic_stringstream</tt> (27.7.4 [stringstream]),
-<tt>basic_istringstream</tt> (27.7.2 [istringstream]), and
-<tt>basic_ostringstream</tt> (27.7.3 [ostringstream]) are inconsistent
-in their definition of the type <tt>traits_type</tt>: For
-<tt>istringstream</tt>, this type is defined, for the other two it is
-not. This should be consistent.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p><b>Proposed resolution:</b></p> <p>To the declarations of
-<tt>basic_ostringstream</tt> (27.7.3 [ostringstream]) and
-<tt>basic_stringstream</tt> (27.7.4 [stringstream]) add:</p>
-<blockquote>
-<pre>typedef traits traits_type;</pre>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="171"></a>171. Strange <tt>seekpos()</tt> semantics due to joint position</h3>
-<p><b>Section:</b> 27.8.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 [filebuf] paragraph 3, it is stated that a joint input and
-output position is maintained by <tt>basic_filebuf</tt>. Still, the
-description of <tt>seekpos()</tt> seems to talk about different file
-positions. In particular, it is unclear (at least to me) what is
-supposed to happen to the output buffer (if there is one) if only the
-input position is changed. The standard seems to mandate that the
-output buffer is kept and processed as if there was no positioning of
-the output position (by changing the input position). Of course, this
-can be exactly what you want if the flag <tt>ios_base::ate</tt> is
-set. However, I think, the standard should say something like
-this:</p>
-<ul>
- <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
- changed and the call fails. Otherwise, the joint read and write position is
- altered to correspond to <tt>sp</tt>.</li>
- <li>If there is an output buffer, the output sequences is updated and any
- unshift sequence is written before the position is altered.</li>
- <li>If there is an input buffer, the input sequence is updated after the
- position is altered.</li>
-</ul>
-<p>Plus the appropriate error handling, that is...</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
-paragraph 14 from:</p>
-<blockquote>
- <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
- ios_base::out);</p>
- <p>Alters the file position, if possible, to correspond to the position stored
- in sp (as described below).</p>
- <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
- the input sequence</p>
- <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
- any unshift sequence, and set the file position to sp.</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
- ios_base::out);</p>
- <p>Alters the file position, if possible, to correspond to the position stored
- in sp (as described below). Altering the file position performs as follows:</p>
- <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
- write any unshift sequence;</p>
- <p>2. set the file position to sp;</p>
- <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
- <p>where om is the open mode passed to the last call to open(). The operation
- fails if is_open() returns false.</p>
-</blockquote>
-
-<p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
-
-<p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="172"></a>172. Inconsistent types for <tt>basic_istream::ignore()</tt></h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Greg Comeau, Dietmar Khl <b>Date:</b> 1999-07-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 27.6.1.1 [istream] the function
-<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
-argument. However, in 27.6.1.3 [istream.unformatted]
-paragraph 23 the first argument is of type <tt>int.</tt></p>
-
-<p>As far as I can see this is not really a contradiction because
-everything is consistent if <tt>streamsize</tt> is typedef to be
-<tt>int</tt>. However, this is almost certainly not what was
-intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
-as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
-
-<p>Darin Adler also
-submitted this issue, commenting: Either 27.6.1.1 should be modified
-to show a first parameter of type int, or 27.6.1.3 should be modified
-to show a first parameter of type streamsize and use
-numeric_limits&lt;streamsize&gt;::max.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.6.1.3 [istream.unformatted] paragraph 23 and 24, change both uses
-of <tt>int</tt> in the description of <tt>ignore()</tt> to
-<tt>streamsize</tt>.</p>
-
-
-
-
-<hr>
-<h3><a name="173"></a>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt></h3>
-<p><b>Section:</b> 27.8.1.5 [filebuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Greg Comeau, Dietmar Khl <b>Date:</b> 1999-07-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.virtuals">issues</a> in [filebuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-In 27.8.1.1 [filebuf] the function <tt>setbuf()</tt> gets an
-object of type <tt>streamsize</tt> as second argument. However, in
-27.8.1.5 [filebuf.virtuals] paragraph 9 the second argument is of type
-<tt>int</tt>.
-</p>
-
-<p>
-As far as I can see this is not really a contradiction because
-everything is consistent if <tt>streamsize</tt> is typedef to be
-<tt>int</tt>. However, this is almost certainly not what was
-intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
-as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.8.1.5 [filebuf.virtuals] paragraph 9, change all uses of
-<tt>int</tt> in the description of <tt>setbuf()</tt> to
-<tt>streamsize</tt>.</p>
-
-
-
-
-<hr>
-<h3><a name="174"></a>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt></h3>
-<p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>According to paragraph 1 of this section, <tt>streampos</tt> is the
-type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
-paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change D.6 [depr.ios.members] paragraph 1 from "<tt>typedef
-OFF_T streampos;</tt>" to "<tt>typedef POS_T
-streampos;</tt>"</p>
-
-
-
-
-<hr>
-<h3><a name="175"></a>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3>
-<p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>According to paragraph 8 of this section, the methods
-<tt>basic_streambuf::pubseekpos()</tt>,
-<tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
-"may" be overloaded by a version of this function taking the
-type <tt>ios_base::open_mode</tt> as last argument argument instead of
-<tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
-in this section to be an alias for one of the integral types). The
-clause specifies, that the last argument has a default argument in
-three cases. However, this generates an ambiguity with the overloaded
-version because now the arguments are absolutely identical if the last
-argument is not specified.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In D.6 [depr.ios.members] paragraph 8, remove the default arguments for
-<tt>basic_streambuf::pubseekpos()</tt>,
-<tt>basic_ifstream::open()</tt>, and
-<tt>basic_ofstream::open().</tt></p>
-
-
-
-
-<hr>
-<h3><a name="176"></a>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3>
-<p><b>Section:</b> D.6 [depr.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 1999-07-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.ios.members">issues</a> in [depr.ios.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The "overload" for the function <tt>exceptions()</tt> in
-paragraph 8 gives the impression that there is another function of
-this function defined in class <tt>ios_base</tt>. However, this is not
-the case. Thus, it is hard to tell how the semantics (paragraph 9) can
-be implemented: "Call the corresponding member function specified
-in clause 27 [input.output]."</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In D.6 [depr.ios.members] paragraph 8, move the declaration of the
-function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
-
-
-
-
-<hr>
-<h3><a name="179"></a>179. Comparison of const_iterators to iterators doesn't work</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 1998-07-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Currently the following will not compile on two well-known standard
-library implementations:</p>
-
-<blockquote>
- <pre>#include &lt;set&gt;
-using namespace std;
-
-void f(const set&lt;int&gt; &amp;s)
-{
- set&lt;int&gt;::iterator i;
- if (i==s.end()); // s.end() returns a const_iterator
-}</pre>
-</blockquote>
-
-<p>
-The reason this doesn't compile is because operator== was implemented
-as a member function of the nested classes set:iterator and
-set::const_iterator, and there is no conversion from const_iterator to
-iterator. Surprisingly, (s.end() == i) does work, though, because of
-the conversion from iterator to const_iterator.
-</p>
-
-<p>
-I don't see a requirement anywhere in the standard that this must
-work. Should there be one? If so, I think the requirement would need
-to be added to the tables in section 24.1.1. I'm not sure about the
-wording. If this requirement existed in the standard, I would think
-that implementors would have to make the comparison operators
-non-member functions.</p>
-
-<p>This issues was also raised on comp.std.c++ by Darin
-Adler.&nbsp; The example given was:</p>
-
-<blockquote>
- <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
-std::deque&lt;int&gt;::const_iterator ci)
-{
-return i == ci;
-}</pre>
-</blockquote>
-
-<p>Comment from John Potter:</p>
-<blockquote>
- <p>
- In case nobody has noticed, accepting it will break reverse_iterator.
- </p>
-
- <p>
- The fix is to make the comparison operators templated on two types.
- </p>
-
- <pre> template &lt;class Iterator1, class Iterator2&gt;
- bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
- reverse_iterator&lt;Iterator2&gt; const&amp; y);
- </pre>
-
- <p>
- Obviously: return x.base() == y.base();
- </p>
-
- <p>
- Currently, no reverse_iterator to const_reverse_iterator compares are
- valid.
- </p>
-
- <p>
- BTW, I think the issue is in support of bad code. Compares should be
- between two iterators of the same type. All std::algorithms require
- the begin and end iterators to be of the same type.
- </p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Insert this paragraph after 23.1 [container.requirements] paragraph 7:</p>
-<blockquote>
- <p>In the expressions</p>
- <pre> i == j
- i != j
- i &lt; j
- i &lt;= j
- i &gt;= j
- i &gt; j
- i - j
- </pre>
- <p>Where i and j denote objects of a container's iterator type,
- either or both may be replaced by an object of the container's
- const_iterator type referring to the same element with no
- change in semantics.</p>
-</blockquote>
-
-<p><i>[post-Toronto: Judy supplied a proposed resolution saying that
-<tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
-iterator comparison and difference operations.]</i></p>
-
-
-<p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
-explicitly listed expressions; there was concern that the previous
-proposed resolution was too informal.]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-The LWG believes it is clear that the above wording applies only to
-the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
-where <tt>X</tt> is a container. There is no requirement that
-<tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
-can be mixed. If mixing them is considered important, that's a
-separate issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
-</p>
-
-
-
-
-<hr>
-<h3><a name="181"></a>181. make_pair() unintended behavior</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The claim has surfaced in Usenet that expressions such as<br>
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
-<br>
-are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
-parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
-<br>
-I doubt anyone intended that behavior...
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 20.2 [utility], paragraph 1 change the following
-declaration of make_pair():</p>
-<blockquote>
- <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
-</blockquote>
-<p> In 20.2.3 [pairs] paragraph 7 and the line before, change:</p>
-<blockquote>
-<pre>template &lt;class T1, class T2&gt;
-pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
-</blockquote>
-<p>to:</p>
-<blockquote>
-<pre>template &lt;class T1, class T2&gt;
-pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
-</blockquote>
-<p>and add the following footnote to the effects clause:</p>
-<blockquote>
- <p> According to 12.8 [class.copy], an implementation is permitted
- to not perform a copy of an argument, thus avoiding unnecessary
- copies.</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>Two potential fixes were suggested by Matt Austern and Dietmar
-Khl, respectively, 1) overloading with array arguments, and 2) use of
-a reference_traits class with a specialization for arrays. Andy
-Koenig suggested changing to pass by value. In discussion, it appeared
-that this was a much smaller change to the standard that the other two
-suggestions, and any efficiency concerns were more than offset by the
-advantages of the solution. Two implementors reported that the
-proposed resolution passed their test suites.</p>
-
-
-
-
-<hr>
-<h3><a name="182"></a>182. Ambiguous references to size_t</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Al Stevens <b>Date:</b> 1999-08-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Many references to <tt> size_t</tt> throughout the document
-omit the <tt> std::</tt> namespace qualification.</p> <p>For
-example, 17.4.3.5 [replacement.functions] paragraph 2:</p>
-<blockquote>
-<pre> operator new(size_t)
- operator new(size_t, const std::nothrow_t&amp;)
- operator new[](size_t)
- operator new[](size_t, const std::nothrow_t&amp;)</pre>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p> In 17.4.3.5 [replacement.functions] paragraph 2: replace:</p>
-<blockquote>
-<p><tt> - operator new(size_t)<br>
- - operator new(size_t, const std::nothrow_t&amp;)<br>
- - operator new[](size_t)<br>
- - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
-</blockquote>
-<p> by:</p>
-<blockquote>
-<pre>- operator new(std::size_t)
-- operator new(std::size_t, const std::nothrow_t&amp;)
-- operator new[](std::size_t)
-- operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
-</blockquote>
-<p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
-<blockquote>
- <p>The typedef members pointer, const_pointer, size_type, and difference_type
- are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
-</blockquote>
-<p>&nbsp;by:</p>
-<blockquote>
- <p>The typedef members pointer, const_pointer, size_type, and difference_type
- are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
- respectively.</p>
-</blockquote>
-<p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
-<blockquote>
- <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
- <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
- is unspecified when or how often this function is called. The use of hint is
- unspecified, but intended as an aid to locality if an implementation so
- desires.</p>
-</blockquote>
-<p>by:</p>
-<blockquote>
- <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
- <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
- it is unspecified when or how often this function is called. The use of hint
- is unspecified, but intended as an aid to locality if an implementation so
- desires.</p>
-</blockquote>
-<p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
-<blockquote>
- <p>In Table 37, X denotes a Traits class defining types and functions for the
- character container type CharT; c and d denote values of type CharT; p and q
- denote values of type const CharT*; s denotes a value of type CharT*; n, i and
- j denote values of type size_t; e and f denote values of type X::int_type; pos
- denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
-</blockquote>
-<p>by:</p>
-<blockquote>
- <p>In Table 37, X denotes a Traits class defining types and functions for the
- character container type CharT; c and d denote values of type CharT; p and q
- denote values of type const CharT*; s denotes a value of type CharT*; n, i and
- j denote values of type std::size_t; e and f denote values of type X::int_type;
- pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
-</blockquote>
-<p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
-X::length(p): "size_t" by "std::size_t".</p>
-<p> In [lib.std.iterator.tags] 24.3.3, paragraph 2: replace:<br>
-&nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
- by:<br>
-&nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
-<p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
-declaration of template &lt;class charT&gt; class ctype.<br>
-<br>
- In [lib.iterator.traits] 24.3.1, paragraph 2 put namespace std { ...} around the declaration of:<br>
-<br>
-&nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
-&nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
-&nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes correcting names like <tt>size_t</tt> and
-<tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
-to be essentially editorial. There there can't be another size_t or
-ptrdiff_t meant anyway because, according to 17.4.3.2.4 [extern.types],</p>
-
-<blockquote><p>
-For each type T from the Standard C library, the types ::T and std::T
-are reserved to the implementation and, when defined, ::T shall be
-identical to std::T.
-</p></blockquote>
-
-<p>The issue is treated as a Defect Report to make explicit the Project
-Editor's authority to make this change.</p>
-
-<p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
-request of the LWG.]</i></p>
-
-
-<p><i>[Toronto: This is tangentially related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, but only tangentially: the intent of this issue is to
-address use of the name <tt>size_t</tt> in contexts outside of
-namespace std, such as in the description of <tt>::operator new</tt>.
-The proposed changes should be reviewed to make sure they are
-correct.]</i></p>
-
-
-<p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
-them to be correct.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="183"></a>183. I/O stream manipulators don't work for wide character streams</h3>
-<p><b>Section:</b> 27.6.3 [std.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andy Sawyer <b>Date:</b> 1999-07-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#std.manip">issues</a> in [std.manip].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>27.6.3 [std.manip] paragraph 3 says (clause numbering added for
-exposition):</p>
-<blockquote>
-<p>Returns: An object s of unspecified type such that if [1] out is an (instance
-of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
-called, and if [2] in is an (instance of) basic_istream then the expression
-in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
-f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
-str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
-out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
-has type istream&amp; and value in.</p>
-</blockquote>
-<p>Given the definitions [1] and [2] for out and in, surely [3] should read:
-"The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
-[4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
-..."</p>
-<p>If the wording in the standard is correct, I can see no way of implementing
-any of the manipulators so that they will work with wide character streams.</p>
-<p>e.g. wcout &lt;&lt; setbase( 16 );</p>
-<p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
-doesn't).</p>
-<p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
-8. In addition, Para 6 [setfill] has a similar error, but relates only to
-ostreams.</p>
-<p>I'd be happier if there was a better way of saying this, to make it clear
-that the value of the expression is "the same specialization of
-basic_ostream as out"&amp;</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace section 27.6.3 [std.manip] except paragraph 1 with the
-following:</p>
-<blockquote>
-<p>2- The type designated smanip in each of the following function
-descriptions is implementation-specified and may be different for each
-function.<br>
-<br>
-<tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
-<br>
--3- Returns: An object s of unspecified type such that if out is an
-instance of basic_ostream&lt;charT,traits&gt; then the expression
-out&lt;&lt;s behaves
-as if f(s, mask) were called, or if in is an instance of
-basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
-behaves as if
-f(s, mask) were called. The function f can be defined as:*<br>
-<br>
-[Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws)
-clears ios_base::skipws in the format flags stored in the
-basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt;
-noskipws), and the expression cout &lt;&lt;
-resetiosflags(ios_base::showbase) clears
-ios_base::showbase in the format flags stored in the
-basic_ostream&lt;charT,traits&gt; object cout (the same as cout
-&lt;&lt;
-noshowbase). --- end footnote]<br>
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
-&nbsp;&nbsp; {<br>
-&nbsp;&nbsp; // reset specified flags<br>
-&nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
-&nbsp;&nbsp; return str;<br>
-&nbsp;&nbsp; }<br>
-</tt><br>
-The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
-The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
-<br>
-&nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
-<br>
--4- Returns: An object s of unspecified type such that if out is an
-instance of basic_ostream&lt;charT,traits&gt; then the expression
-out&lt;&lt;s behaves
-as if f(s, mask) were called, or if in is an instance of
-basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
-behaves as if f(s,
-mask) were called. The function f can be defined as:<br>
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
-&nbsp;&nbsp; {<br>
-&nbsp;&nbsp; // set specified flags<br>
-&nbsp;&nbsp; str.setf(mask);<br>
-&nbsp;&nbsp; return str;<br>
-&nbsp;&nbsp; }<br>
-</tt><br>
-The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
-The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
-<br>
-<tt>smanip setbase(int base);</tt><br>
-<br>
--5- Returns: An object s of unspecified type such that if out is an
-instance of basic_ostream&lt;charT,traits&gt; then the expression
-out&lt;&lt;s behaves
-as if f(s, base) were called, or if in is an instance of
-basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
-behaves as if f(s,
-base) were called. The function f can be defined as:<br>
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
-&nbsp;&nbsp; {<br>
-&nbsp;&nbsp; // set basefield<br>
-&nbsp;&nbsp; str.setf(base == 8 ? ios_base::oct :<br>
-&nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
-&nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
-&nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
-&nbsp;&nbsp; return str;<br>
-&nbsp;&nbsp; }<br>
-</tt><br>
-The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
-The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
-<br>
-<tt>smanip setfill(char_type c);<br>
-</tt><br>
--6- Returns: An object s of unspecified type such that if out is (or is
-derived from) basic_ostream&lt;charT,traits&gt; and c has type charT
-then the
-expression out&lt;&lt;s behaves as if f(s, c) were called. The function
-f can be
-defined as:<br>
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
-&nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
-&nbsp;&nbsp; {<br>
-&nbsp;&nbsp; // set fill character<br>
-&nbsp;&nbsp; str.fill(c);<br>
-&nbsp;&nbsp; return str;<br>
-&nbsp;&nbsp; }<br>
-</tt><br>
-The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
-<br>
-<tt>smanip setprecision(int n);</tt><br>
-<br>
--7- Returns: An object s of unspecified type such that if out is an
-instance of basic_ostream&lt;charT,traits&gt; then the expression
-out&lt;&lt;s behaves
-as if f(s, n) were called, or if in is an instance of
-basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
-behaves as if f(s, n)
-were called. The function f can be defined as:<br>
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
-&nbsp;&nbsp; {<br>
-&nbsp;&nbsp; // set precision<br>
-&nbsp;&nbsp; str.precision(n);<br>
-&nbsp;&nbsp; return str;<br>
-&nbsp;&nbsp; }<br>
-</tt><br>
-The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
-The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
-.<br>
-<tt>smanip setw(int n);<br>
-</tt><br>
--8- Returns: An object s of unspecified type such that if out is an
-instance of basic_ostream&lt;charT,traits&gt; then the expression
-out&lt;&lt;s behaves
-as if f(s, n) were called, or if in is an instance of
-basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
-behaves as if f(s, n)
-were called. The function f can be defined as:<br>
-<br>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
-&nbsp;&nbsp; {<br>
-&nbsp;&nbsp; // set width<br>
-&nbsp;&nbsp; str.width(n);<br>
-&nbsp;&nbsp; return str;<br>
-&nbsp;&nbsp; }<br>
-</tt><br>
-The expression out&lt;&lt;s has type
-basic_ostream&lt;charT,traits&gt;&amp; and value out. The expression
-in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
-in.
-</p>
-</blockquote>
-
-<p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
-the proposed resolution.]</i></p>
-
-
-<p><i>[Tokyo - The LWG noted that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> involves
-the same paragraphs.]</i></p>
-
-
-<p><i>[Post-Tokyo: The issues list maintainer combined the proposed
-resolution of this issue with the proposed resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so
-intertwined that dealing with them separately appear fraught with
-error. The full text was supplied by Bill Plauger; it was cross
-checked against changes supplied by Andy Sawyer. It should be further
-checked by the LWG.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="184"></a>184. numeric_limits&lt;bool&gt; wording problems</h3>
-<p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 1999-07-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>bools are defined by the standard to be of integer types, as per
-3.9.1 [basic.fundamental] paragraph 7. However "integer types"
-seems to have a special meaning for the author of 18.2. The net effect
-is an unclear and confusing specification for
-numeric_limits&lt;bool&gt; as evidenced below.</p>
-
-<p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
-types, the number of non-sign bits in the representation.</p>
-
-<p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
-arithmetical value converts to true.</p>
-
-<p>I don't think it makes sense at all to require
-numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
-be meaningful.</p>
-
-<p>The standard defines what constitutes a signed (resp. unsigned) integer
-types. It doesn't categorize bool as being signed or unsigned. And the set of
-values of bool type has only two elements.</p>
-
-<p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
-to be meaningful.</p>
-
-<p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
-<blockquote>
- <p>For integer types, specifies the base of the representation.186)</p>
-</blockquote>
-
-<p>This disposition is at best misleading and confusing for the standard
-requires a "pure binary numeration system" for integer types as per
-3.9.1/7</p>
-
-<p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
-BCD)."&nbsp; This also erroneous as the standard never defines any integer
-types with base representation other than 2.</p>
-
-<p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
-numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Append to the end of 18.2.1.5 [numeric.special]:</p>
-<blockquote>
- <p>The specialization for bool shall be provided as follows:</p>
- <pre> namespace std {
- template&lt;&gt; class numeric_limits&lt;bool&gt; {
- public:
- static const bool is_specialized = true;
- static bool min() throw() { return false; }
- static bool max() throw() { return true; }
-
- static const int digits = 1;
- static const int digits10 = 0;
- static const bool is_signed = false;
- static const bool is_integer = true;
- static const bool is_exact = true;
- static const int radix = 2;
- static bool epsilon() throw() { return 0; }
- static bool round_error() throw() { return 0; }
-
- static const int min_exponent = 0;
- static const int min_exponent10 = 0;
- static const int max_exponent = 0;
- static const int max_exponent10 = 0;
-
- static const bool has_infinity = false;
- static const bool has_quiet_NaN = false;
- static const bool has_signaling_NaN = false;
- static const float_denorm_style has_denorm = denorm_absent;
- static const bool has_denorm_loss = false;
- static bool infinity() throw() { return 0; }
- static bool quiet_NaN() throw() { return 0; }
- static bool signaling_NaN() throw() { return 0; }
- static bool denorm_min() throw() { return 0; }
-
- static const bool is_iec559 = false;
- static const bool is_bounded = true;
- static const bool is_modulo = false;
-
- static const bool traps = false;
- static const bool tinyness_before = false;
- static const float_round_style round_style = round_toward_zero;
- };
- }</pre>
-</blockquote>
-
-<p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
-rather than more general wording in the original proposed
-resolution.]</i></p>
-
-
-<p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
-Josuttis provided the above wording.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="185"></a>185. Questionable use of term "inline"</h3>
-<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> UK Panel <b>Date:</b> 1999-07-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Paragraph 4 of 20.6 [function.objects] says:</p>
-<blockquote>
- <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
- a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
- the addition and the negation. end example]</p>
-</blockquote>
-<p>(Note: The "addition" referred to in the above is in para 3) we can
-find no other wording, except this (non-normative) example which suggests that
-any "inlining" will take place in this case.</p>
-<p>Indeed both:</p>
-<blockquote>
- <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
- unspecified whether any global functions in the C++ Standard Library
- are defined as inline (7.1.2).</p>
-</blockquote>
-<p>and</p>
-<blockquote>
- <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
- unspecified whether any member functions in the C++ Standard Library
- are defined as inline (7.1.2).</p>
-</blockquote>
-<p>take care to state that this may indeed NOT be the case.</p>
-<p>Thus the example "mandates" behavior that is explicitly
-not required elsewhere.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 20.6 [function.objects] paragraph 1, remove the sentence:</p>
-<blockquote>
-<p>They are important for the effective use of the library.</p>
-</blockquote>
-<p>Remove 20.6 [function.objects] paragraph 2, which reads:</p>
-<blockquote>
- <p> Using function objects together with function templates
- increases the expressive power of the library as well as making the
- resulting code much more efficient.</p>
-</blockquote>
-<p>In 20.6 [function.objects] paragraph 4, remove the sentence:</p>
-<blockquote>
- <p>The corresponding functions will inline the addition and the
- negation.</p>
-</blockquote>
-
-<p><i>[Kona: The LWG agreed there was a defect.]</i></p>
-
-<p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="186"></a>186. bitset::set() second parameter should be bool</h3>
-<p><b>Section:</b> 23.3.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Darin Adler <b>Date:</b> 1999-08-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In section 23.3.5.2 [bitset.members], paragraph 13 defines the
-bitset::set operation to take a second parameter of type int. The
-function tests whether this value is non-zero to determine whether to
-set the bit to true or false. The type of this second parameter should
-be bool. For one thing, the intent is to specify a Boolean value. For
-another, the result type from test() is bool. In addition, it's
-possible to slice an integer that's larger than an int. This can't
-happen with bool, since conversion to bool has the semantic of
-translating 0 to false and any non-zero value to true.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 23.3.5 [template.bitset] Para 1 Replace:</p>
-<blockquote>
-<pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
-</blockquote>
-<p>With:</p>
-<blockquote>
- <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
-</blockquote>
-<p>In 23.3.5.2 [bitset.members] Para 12(.5) Replace:</p>
-<blockquote>
- <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
-</blockquote>
-<p>With:</p>
-<blockquote>
- <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
-</blockquote>
-
-<p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
-on better P/R wording.]</i></p>
-
-<p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p><tt>bool</tt> is a better choice. It is believed that binary
-compatibility is not an issue, because this member function is
-usually implemented as <tt>inline</tt>, and because it is already
-the case that users cannot rely on the type of a pointer to a
-nonvirtual member of a standard library class.</p>
-
-
-
-
-
-<hr>
-<h3><a name="187"></a>187. iter_swap underspecified</h3>
-<p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The description of iter_swap in 25.2.2 paragraph 7,says that it
-``exchanges the values'' of the objects to which two iterators
-refer.<br> <br> What it doesn't say is whether it does so using swap
-or using the assignment operator and copy constructor.<br> <br> This
-question is an important one to answer, because swap is specialized to
-work efficiently for standard containers.<br> For example:</p>
-<blockquote>
-<pre>vector&lt;int&gt; v1, v2;
-iter_swap(&amp;v1, &amp;v2);</pre>
-</blockquote>
-<p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
-Or is it equivalent to</p>
-<blockquote>
-<pre>{
-vector&lt;int&gt; temp = v1;
-v1 = v2;
-v2 = temp;
-}</pre>
-</blockquote>
-<p>The first alternative is O(1); the second is O(n).</p>
-<p>A LWG member, Dave Abrahams, comments:</p>
-<blockquote>
-<p>Not an objection necessarily, but I want to point out the cost of
-that requirement:</p>
- <blockquote>
-<p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
- </blockquote>
-<p>can currently be specialized to be more efficient than
-iter_swap(T*,T*) for many T (by using splicing). Your proposal would
-make that optimization illegal.&nbsp;</p>
-</blockquote>
-
-<p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
-which are no longer permitted.]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
-<blockquote>
-<p>Exchanges the values pointed to by the two iterators a and b.</p>
-</blockquote>
-<p>to</p>
-<blockquote>
-<p><tt>swap(*a, *b)</tt>.</p>
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>It's useful to say just what <tt>iter_swap</tt> does. There may be
- some iterators for which we want to specialize <tt>iter_swap</tt>,
- but the fully general version should have a general specification.</p>
-
-<p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
-iter_swap should not be specialized as suggested above. That would do
-much more than exchanging the two iterators' values: it would change
-predecessor/successor relationships, possibly moving the iterator from
-one list to another. That would surely be inappropriate.</p>
-
-
-
-
-
-<hr>
-<h3><a name="189"></a>189. setprecision() not specified correctly</h3>
-<p><b>Section:</b> 27.4.2.2 [fmtflags.state] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 1999-08-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fmtflags.state">issues</a> in [fmtflags.state].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
-and includes a parenthetical note saying that it is the number of
-digits after the decimal point.<br>
-<br>
-This claim is not strictly correct. For example, in the default
-floating-point output format, setprecision sets the number of
-significant digits printed, not the number of digits after the decimal
-point.<br>
-<br>
-I would like the committee to look at the definition carefully and
-correct the statement in 27.4.2.2</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Remove from 27.4.2.2 [fmtflags.state], paragraph 9, the text
-"(number of digits after the decimal point)".</p>
-
-
-
-
-<hr>
-<h3><a name="193"></a>193. Heap operations description incorrect</h3>
-<p><b>Section:</b> 25.3.6 [alg.heap.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Markus Mauhart <b>Date:</b> 1999-09-24</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a></p>
-<p><b>Discussion:</b></p>
-<p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
-is<br>
-<br>
-&nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
-<br>
-I think this is incorrect and should be changed to the wording in the proposed
-resolution.</p>
-<p>Actually there are two independent changes:</p>
-<blockquote>
- <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
- [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
- <p>B-Take
-'an oldest' from that equivalence class, otherwise the heap functions
-could not be used for a priority queue as explained in 23.2.3.2.2
-[lib.priqueue.members] (where I assume that a "priority queue" respects
-priority AND time).</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 25.3.6 [alg.heap.operations] property (1) from:</p>
-<blockquote>
- <p>(1) *a is the largest element</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>(1) There is no element greater than <tt>*a</tt></p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="195"></a>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3>
-<p><b>Section:</b> 27.6.1.1.3 [istream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-10-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::sentry">issues</a> in [istream::sentry].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
-What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
-reaches eof while skipping whitespace? 27.6.1.1.2/5 suggests it
-should set failbit. Should it set eofbit as well? The standard
-doesn't seem to answer that question.</p>
-
-<p>On the one hand, nothing in 27.6.1.1.3 [istream::sentry] says that
-<tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit. On the
-other hand, 27.6.1.1 [istream] paragraph 4 says that if
-extraction from a <tt>streambuf</tt> "returns
-<tt>traits::eof()</tt>, then the input function, except as explicitly
-noted otherwise, completes its actions and does
-<tt>setstate(eofbit)"</tt>. So the question comes down to
-whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
-input function.</p>
-
-<p>Comments from Jerry Schwarz:</p>
-<blockquote>
-<p>It was always my intention that eofbit should be set any time that a
-virtual returned something to indicate eof, no matter what reason
-iostream code had for calling the virtual.</p>
-<p>
-The motivation for this is that I did not want to require streambufs
-to behave consistently if their virtuals are called after they have
-signaled eof.</p>
-<p>
-The classic case is a streambuf reading from a UNIX file. EOF isn't
-really a state for UNIX file descriptors. The convention is that a
-read on UNIX returns 0 bytes to indicate "EOF", but the file
-descriptor isn't shut down in any way and future reads do not
-necessarily also return 0 bytes. In particular, you can read from
-tty's on UNIX even after they have signaled "EOF". (It
-isn't always understood that a ^D on UNIX is not an EOF indicator, but
-an EOL indicator. By typing a "line" consisting solely of
-^D you cause a read to return 0 bytes, and by convention this is
-interpreted as end of file.)</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
-<blockquote>
-<p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
-returns <tt>traits::eof()</tt>, the function calls
-<tt>setstate(failbit | eofbit)</tt> (which may throw
-<tt>ios_base::failure</tt>).
-</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="198"></a>198. Validity of pointers and references unspecified after iterator destruction</h3>
-<p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 1999-11-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Is a pointer or reference obtained from an iterator still valid after
-destruction of the iterator?
-</p>
-<p>
-Is a pointer or reference obtained from an iterator still valid after the value
-of the iterator changes?
-</p>
-<blockquote>
-<pre>#include &lt;iostream&gt;
-#include &lt;vector&gt;
-#include &lt;iterator&gt;
-
-int main()
-{
- typedef std::vector&lt;int&gt; vec_t;
- vec_t v;
- v.push_back( 1 );
-
- // Is a pointer or reference obtained from an iterator still
- // valid after destruction of the iterator?
- int * p = &amp;*v.begin();
- std::cout &lt;&lt; *p &lt;&lt; '\n'; // OK?
-
- // Is a pointer or reference obtained from an iterator still
- // valid after the value of the iterator changes?
- vec_t::iterator iter( v.begin() );
- p = &amp;*iter++;
- std::cout &lt;&lt; *p &lt;&lt; '\n'; // OK?
-
- return 0;
-}
-</pre>
-</blockquote>
-
-<p>The standard doesn't appear to directly address these
-questions. The standard needs to be clarified. At least two real-world
-cases have been reported where library implementors wasted
-considerable effort because of the lack of clarity in the
-standard. The question is important because requiring pointers and
-references to remain valid has the effect for practical purposes of
-prohibiting iterators from pointing to cached rather than actual
-elements of containers.</p>
-
-<p>The standard itself assumes that pointers and references obtained
-from an iterator are still valid after iterator destruction or
-change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 [reverse.iter.conv], which returns a reference, defines
-effects:</p>
-
-<blockquote>
- <pre>Iterator tmp = current;
-return *--tmp;</pre>
-</blockquote>
-<p>The definition of reverse_iterator::operator-&gt;(), 24.4.1.3.4
-[reverse.iter.op.star], which returns a pointer, defines effects:</p>
-<blockquote>
- <pre>return &amp;(operator*());</pre>
-</blockquote>
-
-<p>Because the standard itself assumes pointers and references remain
-valid after iterator destruction or change, the standard should say so
-explicitly. This will also reduce the chance of user code breaking
-unexpectedly when porting to a different standard library
-implementation.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add a new paragraph to 24.1 [iterator.requirements]:</p>
-<blockquote><p>
-Destruction of an iterator may invalidate pointers and references
-previously obtained from that iterator.
-</p></blockquote>
-
-<p>Replace paragraph 1 of 24.4.1.3.3 [reverse.iter.conv] with:</p>
-
-<blockquote>
-<p><b>Effects:</b></p>
-<pre> this-&gt;tmp = current;
- --this-&gt;tmp;
- return *this-&gt;tmp;
-</pre>
-
-<p>
-[<i>Note:</i> This operation must use an auxiliary member variable,
-rather than a temporary variable, to avoid returning a reference that
-persists beyond the lifetime of its associated iterator. (See
-24.1 [iterator.requirements].) The name of this member variable is shown for
-exposition only. <i>--end note</i>]
-</p>
-</blockquote>
-
-<p><i>[Post-Tokyo: The issue has been reformulated purely
-in terms of iterators.]</i></p>
-
-
-<p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
-assumption by reverse_iterator. The issue and proposed resolution was
-reformulated yet again to reflect this reality.]</i></p>
-
-
-<p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
-assumes its underlying iterator has persistent pointers and
-references. Andy Koenig pointed out that it is possible to rewrite
-reverse_iterator so that it no longer makes such an assupmption.
-However, this issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>. If we
-decide it is intentional that <tt>p[n]</tt> may return by value
-instead of reference when <tt>p</tt> is a Random Access Iterator,
-other changes in reverse_iterator will be necessary.]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>This issue has been discussed extensively. Note that it is
-<i>not</i> an issue about the behavior of predefined iterators. It is
-asking whether or not user-defined iterators are permitted to have
-transient pointers and references. Several people presented examples
-of useful user-defined iterators that have such a property; examples
-include a B-tree iterator, and an "iota iterator" that doesn't point
-to memory. Library implementors already seem to be able to cope with
-such iterators: they take pains to avoid forming references to memory
-that gets iterated past. The only place where this is a problem is
-<tt>reverse_iterator</tt>, so this issue changes
-<tt>reverse_iterator</tt> to make it work.</p>
-
-<p>This resolution does not weaken any guarantees provided by
-predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
-Clause 23 should be reviewed to make sure that guarantees for
-predefined iterators are as strong as users expect.</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="199"></a>199. What does <tt>allocate(0)</tt> return?</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-11-19</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Suppose that <tt>A</tt> is a class that conforms to the
-Allocator requirements of Table 32, and <tt>a</tt> is an
-object of class <tt>A</tt> What should be the return
-value of <tt>a.allocate(0)</tt>? Three reasonable
-possibilities: forbid the argument <tt>0</tt>, return
-a null pointer, or require that the return value be a
-unique non-null pointer.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a note to the <tt>allocate</tt> row of Table 32:
-"[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
-
-
-<p><b>Rationale:</b></p>
-<p>A key to understanding this issue is that the ultimate use of
-allocate() is to construct an iterator, and that iterator for zero
-length sequences must be the container's past-the-end
-representation. Since this already implies special case code, it
-would be over-specification to mandate the return value.
-</p>
-
-
-
-
-<hr>
-<h3><a name="200"></a>200. Forward iterator requirements don't allow constant iterators</h3>
-<p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 1999-11-19</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In table 74, the return type of the expression <tt>*a</tt> is given
-as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
-For constant iterators, however, this is wrong. ("Value type"
-is never defined very precisely, but it is clear that the value type
-of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
-<tt>int</tt>, not <tt>const int</tt>.)
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
-return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
-if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
-In the <tt>a-&gt;m</tt> row, change the return type from
-"<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
-otherwise <tt>const U&amp;</tt>".
-</p>
-
-<p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
-there are multiple const problems with the STL portion of the library
-and that these should be addressed as a single package.&nbsp; Note
-that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#180">180</a> has already been declared NAD Future for
-that very reason.]</i></p>
-
-
-<p><i>[Redmond: the LWG thinks this is separable from other constness
-issues. This issue is just cleanup; it clarifies language that was
-written before we had iterator_traits. Proposed resolution was
-modified: the original version only discussed *a. It was pointed out
-that we also need to worry about *r++ and a-&gt;m.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="201"></a>201. Numeric limits terminology wrong</h3>
-<p><b>Section:</b> 18.2.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Stephen Cleary <b>Date:</b> 1999-12-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In some places in this section, the terms "fundamental types" and
-"scalar types" are used when the term "arithmetic types" is intended.
-The current usage is incorrect because void is a fundamental type and
-pointers are scalar types, neither of which should have
-specializations of numeric_limits.
-</p>
-<p><i>[Lillehammer: it remains true that numeric_limits is using
- imprecise language. However, none of the proposals for changed
- wording are clearer. A redesign of numeric_limits is needed, but this
- is more a task than an open issue.]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 18.2 [support.limits] to:
-</p>
-
-<blockquote>
-<p>
--1- The headers <tt>&lt;limits&gt;</tt>, <tt>&lt;climits&gt;</tt>,
-<tt>&lt;cfloat&gt;</tt>, and <tt>&lt;cinttypes&gt;</tt> supply
-characteristics of implementation-dependent <del>fundamental</del>
-<ins>arithmetic</ins> types (3.9.1).
-</p>
-</blockquote>
-
-<p>
-Change 18.2.1 [limits] to:
-</p>
-
-<blockquote>
-<p>
--1- The <tt>numeric_limits</tt> component provides a C++ program with
-information about various properties of the implementation's
-representation of the <del>fundamental</del> <ins>arithmetic</ins>
-types.
-</p>
-<p>
--2- Specializations shall be provided for each <del>fundamental</del>
-<ins>arithmetic</ins> type, both floating point and integer, including
-<tt>bool</tt>. The member <tt>is_specialized</tt> shall be <tt>true</tt>
-for all such specializations of <tt>numeric_limits</tt>.
-</p>
-<p>
--4- Non-<del>fundamental</del><ins>arithmetic</ins> standard types, such
-as <tt>complex&lt;T&gt;</tt> (26.3.2), shall not have specializations.
-</p>
-</blockquote>
-
-<p>
-Change 18.2.1.1 [numeric.limits] to:
-</p>
-
-<blockquote>
-<p>
-<del>-1- The member <tt>is_specialized</tt> makes it possible to distinguish
-between fundamental types, which have specializations, and non-scalar types,
-which do not.</del>
-</p>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="202"></a>202. unique() effects unclear when predicate not an equivalence relation</h3>
-<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-01-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-What should unique() do if you give it a predicate that is not an
-equivalence relation? There are at least two plausible answers:
-</p>
-
-<blockquote>
-
-<p>
- 1. You can't, because 25.2.8 says that it it "eliminates all but
- the first element from every consecutive group of equal
- elements..." and it wouldn't make sense to interpret "equal" as
- meaning anything but an equivalence relation. [It also doesn't
- make sense to interpret "equal" as meaning ==, because then there
- would never be any sense in giving a predicate as an argument at
- all.]
-</p>
-
-<p>
- 2. The word "equal" should be interpreted to mean whatever the
- predicate says, even if it is not an equivalence relation
- (and in particular, even if it is not transitive).
-</p>
-
-</blockquote>
-
-<p>
-The example that raised this question is from Usenet:
-</p>
-
-<blockquote>
-
-<pre>int f[] = { 1, 3, 7, 1, 2 };
-int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
-
-</blockquote>
-
-<p>
-If one blindly applies the definition using the predicate
-greater&lt;int&gt;, and ignore the word "equal", you get:
-</p>
-
-<blockquote>
-
-<p>
- Eliminates all but the first element from every consecutive group
- of elements referred to by the iterator i in the range [first, last)
- for which *i &gt; *(i - 1).
-</p>
-
-</blockquote>
-
-<p>
-The first surprise is the order of the comparison. If we wanted to
-allow for the predicate not being an equivalence relation, then we
-should surely compare elements the other way: pred(*(i - 1), *i). If
-we do that, then the description would seem to say: "Break the
-sequence into subsequences whose elements are in strictly increasing
-order, and keep only the first element of each subsequence". So the
-result would be 1, 1, 2. If we take the description at its word, it
-would seem to call for strictly DEcreasing order, in which case the
-result should be 1, 3, 7, 2.<br>
-<br>
-In fact, the SGI implementation of unique() does neither: It yields 1,
-3, 7.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 25.2.9 [alg.unique] paragraph 1 to:</p>
-<blockquote><p>
-For a nonempty range, eliminates all but the first element from every
-consecutive group of equivalent elements referred to by the iterator
-<tt>i</tt> in the range [first+1, last) for which the following
-conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
-false</tt>.
-</p></blockquote>
-
-<p>
-Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
-comparison function must be an equivalence relation."
-</p>
-
-<p><i>[Redmond: discussed arguments for and against requiring the
-comparison function to be an equivalence relation. Straw poll:
-14-2-5. First number is to require that it be an equivalence
-relation, second number is to explicitly not require that it be an
-equivalence relation, third number is people who believe they need
-more time to consider the issue. A separate issue: Andy Sawyer
-pointed out that "i-1" is incorrect, since "i" can refer to the first
-iterator in the range. Matt provided wording to address this
-problem.]</i></p>
-
-
-<p><i>[Curaao: The LWG changed "... the range (first,
-last)..." to "... the range [first+1, last)..." for
-clarity. They considered this change close enough to editorial to not
-require another round of review.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG also considered an alternative resolution: change
-25.2.9 [alg.unique] paragraph 1 to:</p>
-
-<blockquote><p>
-For a nonempty range, eliminates all but the first element from every
-consecutive group of elements referred to by the iterator
-<tt>i</tt> in the range (first, last) for which the following
-conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
-false</tt>.
-</p></blockquote>
-
-<p>
-Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
-comparison function need not be an equivalence relation."
-</p>
-
-
-<p>Informally: the proposed resolution imposes an explicit requirement
-that the comparison function be an equivalence relation. The
-alternative resolution does not, and it gives enough information so
-that the behavior of unique() for a non-equivalence relation is
-specified. Both resolutions are consistent with the behavior of
-existing implementations.</p>
-
-
-
-
-
-<hr>
-<h3><a name="206"></a>206. operator new(size_t, nothrow) may become unlinked to ordinary operator new if ordinary version replaced</h3>
-<p><b>Section:</b> 18.5.1.1 [new.delete.single] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 1999-08-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>As specified, the implementation of the nothrow version of operator
-new does not necessarily call the ordinary operator new, but may
-instead simply call the same underlying allocator and return a null
-pointer instead of throwing an exception in case of failure.</p>
-
-<p>Such an implementation breaks code that replaces the ordinary
-version of new, but not the nothrow version. If the ordinary version
-of new/delete is replaced, and if the replaced delete is not
-compatible with pointers returned from the library versions of new,
-then when the replaced delete receives a pointer allocated by the
-library new(nothrow), crash follows.</p>
-
-<p>The fix appears to be that the lib version of new(nothrow) must
-call the ordinary new. Thus when the ordinary new gets replaced, the
-lib version will call the replaced ordinary new and things will
-continue to work.</p>
-
-<p>An alternative would be to have the ordinary new call
-new(nothrow). This seems sub-optimal to me as the ordinary version of
-new is the version most commonly replaced in practice. So one would
-still need to replace both ordinary and nothrow versions if one wanted
-to replace the ordinary version.</p>
-
-<p>Another alternative is to put in clear text that if one version is
-replaced, then the other must also be replaced to maintain
-compatibility. Then the proposed resolution below would just be a
-quality of implementation issue. There is already such text in
-paragraph 7 (under the new(nothrow) version). But this nuance is
-easily missed if one reads only the paragraphs relating to the
-ordinary new.</p>
-
-<p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2158.html">N2158</a>
-has been written explaining the rationale for the proposed resolution below.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 18.5.1.1 [new.delete.single]:
-</p>
-
-<blockquote>
-<pre>void* operator new(std::size_t <i>size</i>, const std::nothrow_t&amp;) throw();
-</pre>
-<blockquote>
-<p>
--5- <i>Effects:</i> Same as above, except that it is called by a placement
-version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
-an error indication, instead of a <tt>bad_alloc</tt> exception.
-</p>
-
-<p>
--6- <i>Replaceable:</i> a C++ program may define a function with this function
-signature that displaces the default version defined by the C++ Standard
-library.
-</p>
-
-<p>
--7- <i>Required behavior:</i> Return a non-null pointer to suitably aligned
-storage (3.7.4), or else return a null pointer. This nothrow version of operator
-new returns a pointer obtained as if acquired from the <ins>(possibly
-replaced)</ins> ordinary version. This requirement is binding on a replacement
-version of this function.
-</p>
-
-<p>
--8- <i>Default behavior:</i>
-</p>
-<ul>
-<li><ins>
-Calls <tt>operator new(<i>size</i>)</tt>.
-</ins></li>
-<li><ins>
-If the call to <tt>operator new(<i>size</i>)</tt> returns normally, returns
-the result of that call, else
-</ins></li>
-<li><ins>
-if the call to <tt>operator new(<i>size</i>)</tt> throws an exception, returns
-a null pointer.
-</ins></li>
-<li><del>
-Executes a loop: Within the loop, the function first attempts to allocate the
-requested storage. Whether the attempt involves a call to the Standard C library
-function <tt>malloc</tt> is unspecified.
-</del></li>
-<li><del>
-Returns a pointer to the allocated storage if the attempt is successful.
-Otherwise, if the last argument to <tt>set_new_handler()</tt> was a null
-pointer, return a null pointer.
-</del></li>
-<li><del>
-Otherwise, the function calls the current <i>new_handler</i> (18.5.2.2). If the
-called function returns, the loop repeats.
-</del></li>
-<li><del>
-The loop terminates when an attempt to allocate the requested storage is
-successful or when a called <i>new_handler</i> function does not return. If the
-called <i>new_handler</i> function terminates by throwing a <tt>bad_alloc
-exception</tt>, the function returns a null pointer.
-</del></li>
-</ul>
-<p>
--9- [<i>Example:</i>
-</p>
-<blockquote><pre>T* p1 = new T; <i>// throws bad_alloc if it fails</i>
-T* p2 = new(nothrow) T; <i>// returns 0 if it fails</i>
-</pre></blockquote>
-<p>
---<i>end example</i>]
-</p>
-</blockquote>
-
-<pre>void operator delete(void* <i>ptr</i>) throw();
-<del>void operator delete(void* <i>ptr</i>, const std::nothrow_t&amp;) throw();</del>
-</pre>
-
-<blockquote>
-<p>
--10- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by a
-<i>delete-expression</i> to render the value of <tt><i>ptr</i></tt> invalid.
-</p>
-<p>
--11- <i>Replaceable:</i> a C++ program may define a function with this function
-signature that displaces the default version defined by the C++ Standard
-library.
-</p>
-<p>
--12- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the value
-returned by an earlier call to the <del>default</del> <ins>(possibly
-replaced)</ins> <tt>operator new(std::size_t)</tt> or <tt>operator
-new(std::size_t, const std::nothrow_t&amp;)</tt>.
-</p>
-<p>
--13- <i>Default behavior:</i>
-</p>
-<ul>
-<li>
-For a null value of <tt><i>ptr</i></tt>, do nothing.
-</li>
-<li>
-Any other value of <tt><i>ptr</i></tt> shall be a value returned earlier by a
-call to the default <tt>operator new</tt>, which was not invalidated by an
-intervening call to <tt>operator delete(void*)</tt> (17.4.3.7). For such a
-non-null value of <tt><i>ptr</i></tt>, reclaims storage allocated by the earlier
-call to the default <tt>operator new</tt>.
-</li>
-</ul>
-<p>
--14- <i>Remarks:</i> It is unspecified under what conditions part or all of
-such reclaimed storage is allocated by a subsequent call to <tt>operator
-new</tt> or any of <tt>calloc</tt>, <tt>malloc</tt>, or <tt>realloc</tt>,
-declared in <tt>&lt;cstdlib&gt;</tt>.
-</p>
-</blockquote>
-
-<pre><ins>void operator delete(void* <i>ptr</i>, const std::nothrow_t&amp;) throw();</ins>
-</pre>
-
-<blockquote>
-<p><ins>
--15- <i>Effects:</i> Same as above, except that it is called by the
-implementation when an exception propagates from a nothrow placement version
-of the <i>new-expression</i> (i.e. when the constructor throws an exception).
-</ins></p>
-<p><ins>
--16- <i>Replaceable:</i> a C++ program may define a function with this function
-signature that displaces the default version defined by the C++ Standard
-library.
-</ins></p>
-<p><ins>
--17- <i>Requires:</i> the value of <tt><i>ptr</i></tt> is null or the
-value returned by an earlier call to the (possibly replaced) <tt>operator
-new(std::size_t)</tt> or <tt>operator new(std::size_t, const
-std::nothrow_t&amp;)</tt>. </ins></p>
-<p><ins>
--18- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt>.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-<p>
-Change 18.5.1.2 [new.delete.array]
-</p>
-
-<blockquote>
-<pre>void* operator new[](std::size_t <i>size</i>, const std::nothrow_t&amp;) throw();
-</pre>
-
-<blockquote>
-<p>
--5- <i>Effects:</i> Same as above, except that it is called by a placement
-version of a <i>new-expression</i> when a C++ program prefers a null pointer result as
-an error indication, instead of a <tt>bad_alloc</tt> exception.
-</p>
-
-<p>
--6- <i>Replaceable:</i> a C++ program can define a function with this function
-signature that displaces the default version defined by the C++ Standard
-library.
-</p>
-
-<p>
--7- <i>Required behavior:</i> <del>Same as for operator <tt>new(std::size_t,
-const std::nothrow_t&amp;)</tt>. This nothrow version of operator <tt>new[]</tt>
-returns a pointer obtained as if acquired from the ordinary version.</del>
-<ins>Return a non-null pointer to suitably aligned storage (3.7.4), or else
-return a null pointer. This nothrow version of operator new returns a pointer
-obtained as if acquired from the (possibly replaced) <tt>operator
-new[](std::size_t <i>size</i>)</tt>. This requirement is binding on a
-replacement version of this function.</ins>
-</p>
-
-<p>
--8- <i>Default behavior:</i> <del>Returns <tt>operator new(<i>size</i>,
-nothrow)</tt>.</del>
-</p>
-
-<ul>
-<li><ins>
-Calls <tt>operator new[](<i>size</i>)</tt>.
-</ins></li>
-<li><ins>
-If the call to <tt>operator new[](<i>size</i>)</tt> returns normally, returns
-the result of that call, else
-</ins></li>
-<li><ins>
-if the call to <tt>operator new[](<i>size</i>)</tt> throws an exception, returns
-a null pointer.
-</ins></li>
-</ul>
-</blockquote>
-
-<pre>void operator delete[](void* <i>ptr</i>) throw();
-void operator delete[](void* <i>ptr</i>, const std::nothrow_t&amp;) throw();
-</pre>
-
-<blockquote>
-<p>
--9- <i>Effects:</i> The <i>deallocation function</i> (3.7.4.2) called by the
-array form of a <i>delete-expression</i> to render the value of
-<tt><i>ptr</i></tt> invalid.
-</p>
-
-<p>
--10- <i>Replaceable:</i> a C++ program can define a function with this function
-signature that displaces the default version defined by the C++ Standard
-library.
-</p>
-
-<p>
--11- <i>Requires:</i> the value of
-<tt><i>ptr</i></tt> is null or the value returned by an earlier call to
-<tt>operator new[](std::size_t)</tt> or <tt>operator new[](std::size_t, const
-std::nothrow_t&amp;)</tt>.
-</p>
-
-<p>
--12- <i>Default behavior:</i> Calls <tt>operator delete(<i>ptr</i>)</tt> or
-<tt>operator delete<ins>[]</ins>(<i>ptr</i><del>, std::nothrow</del>)</tt> respectively.
-</p>
-</blockquote>
-
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>Yes, they may become unlinked, and that is by design. If a user
-replaces one, the user should also replace the other.</p>
-
-<p><i>[
-Reopened due to a gcc conversation between Howard, Martin and Gaby. Forwarding
-or not is visible behavior to the client and it would be useful for the client
-to know which behavior it could depend on.
-]</i></p>
-
-
-<p><i>[
-Batavia: Robert voiced serious reservations about backwards compatibility for
-his customers.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="208"></a>208. Unnecessary restriction on past-the-end iterators</h3>
-<p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Stephen Cleary <b>Date:</b> 2000-02-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
-past-the-end values are always non-singular."</p>
-<p>This places an unnecessary restriction on past-the-end iterators for
-containers with forward iterators (for example, a singly-linked list). If the
-past-the-end value on such a container was a well-known singular value, it would
-still satisfy all forward iterator requirements.</p>
-<p>Removing this restriction would allow, for example, a singly-linked list
-without a "footer" node.</p>
-<p>This would have an impact on existing code that expects past-the-end
-iterators obtained from different (generic) containers being not equal.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 24.1 [iterator.requirements] paragraph 5, the last sentence, from:</p>
-<blockquote>
-<p>Dereferenceable and past-the-end values are always non-singular.</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
-<p>Dereferenceable values are always non-singular.&nbsp;</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>For some kinds of containers, including singly linked lists and
-zero-length vectors, null pointers are perfectly reasonable past-the-end
-iterators. Null pointers are singular.
-</p>
-
-
-
-
-<hr>
-<h3><a name="209"></a>209. basic_string declarations inconsistent</h3>
-<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Igor Stauder <b>Date:</b> 2000-02-11</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In Section 21.3 [basic.string] the basic_string member function
-declarations use a consistent style except for the following functions:</p>
-<blockquote>
- <pre>void push_back(const charT);
-basic_string&amp; assign(const basic_string&amp;);
-void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
-</blockquote>
-<p>- push_back, assign, swap: missing argument name&nbsp;<br>
-- push_back: use of const with charT (i.e. POD type passed by value
-not by reference - should be charT or const charT&amp; )<br>
-- swap: redundant use of template parameters in argument
-basic_string&lt;charT,traits,Allocator&gt;&amp;</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In Section 21.3 [basic.string] change the basic_string member
-function declarations push_back, assign, and swap to:</p>
-<blockquote>
- <pre>void push_back(charT c);
-
-basic_string&amp; assign(const basic_string&amp; str);
-void swap(basic_string&amp; str);</pre>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>Although the standard is in general not consistent in declaration
-style, the basic_string declarations are consistent other than the
-above. The LWG felt that this was sufficient reason to merit the
-change.
-</p>
-
-
-
-
-<hr>
-<h3><a name="210"></a>210. distance first and last confused</h3>
-<p><b>Section:</b> 25 [algorithms] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-02-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#algorithms">issues</a> in [algorithms].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In paragraph 9 of section 25 [algorithms], it is written:</p>
-<blockquote>
- <p> In the description of the algorithms operators + and - are used
- for some of the iterator categories for which they do not have to
- be defined. In these cases the semantics of [...] a-b is the same
- as of<br>
- <br>
- &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt></p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>On the last line of paragraph 9 of section 25 [algorithms] change
-<tt>"a-b"</tt> to <tt>"b-a".</tt></p>
-
-
-<p><b>Rationale:</b></p>
-<p>There are two ways to fix the defect; change the description to b-a
-or change the return to distance(b,a). The LWG preferred the
-former for consistency.</p>
-
-
-
-
-<hr>
-<h3><a name="211"></a>211. operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</h3>
-<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Scott Snyder <b>Date:</b> 2000-02-04</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The description of the stream extraction operator for std::string (section
-21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
-the case that the operator fails to extract any characters from the input
-stream.</p>
-<p>This implies that the typical construction</p>
-<blockquote>
- <pre>std::istream is;
-std::string str;
-...
-while (is &gt;&gt; str) ... ;</pre>
-</blockquote>
-<p>(which tests failbit) is not required to terminate at EOF.</p>
-<p>Furthermore, this is inconsistent with other extraction operators,
-which do include this requirement. (See sections 27.6.1.2 [istream.formatted] and 27.6.1.3 [istream.unformatted]), where this
-requirement is present, either explicitly or implicitly, for the
-extraction operators. It is also present explicitly in the description
-of getline (istream&amp;, string&amp;, charT) in section 21.3.8.9 [string.io] paragraph 8.)</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Insert new paragraph after paragraph 2 in section 21.3.8.9 [string.io]:</p>
-<blockquote>
-
-<p>If the function extracts no characters, it calls
-is.setstate(ios::failbit) which may throw ios_base::failure
-(27.4.4.3).</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="212"></a>212. Empty range behavior unclear for several algorithms</h3>
-<p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Nico Josuttis <b>Date:</b> 2000-02-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The standard doesn't specify what min_element() and max_element() shall
-return if the range is empty (first equals last). The usual implementations
-return last. This problem seems also apply to partition(), stable_partition(),
-next_permutation(), and prev_permutation().</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 25.3.7 [alg.min.max] - Minimum and maximum, paragraphs 7 and
-9, append: Returns last if first==last.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG looked in some detail at all of the above mentioned
-algorithms, but believes that except for min_element() and
-max_element() it is already clear that last is returned if first ==
-last.</p>
-
-
-
-
-<hr>
-<h3><a name="214"></a>214. set::find() missing const overload</h3>
-<p><b>Section:</b> 23.3.3 [set], 23.3.4 [multiset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-02-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#set">issues</a> in [set].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#450">450</a></p>
-<p><b>Discussion:</b></p>
-<p>The specification for the associative container requirements in
-Table 69 state that the find member function should "return
-iterator; const_iterator for constant a". The map and multimap
-container descriptions have two overloaded versions of find, but set
-and multiset do not, all they have is:</p>
-<blockquote>
- <pre>iterator find(const key_type &amp; x) const;</pre>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the prototypes for find(), lower_bound(), upper_bound(), and
-equal_range() in section 23.3.3 [set] and section 23.3.4 [multiset] to each have two overloads:</p>
-<blockquote>
- <pre>iterator find(const key_type &amp; x);
-const_iterator find(const key_type &amp; x) const;</pre>
- <pre>iterator lower_bound(const key_type &amp; x);
-const_iterator lower_bound(const key_type &amp; x) const;</pre>
- <pre>iterator upper_bound(const key_type &amp; x);
-const_iterator upper_bound(const key_type &amp; x) const;</pre>
- <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
-pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
-</blockquote>
-
-<p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
-extending the proposed resolution to lower_bound, upper_bound, and
-equal_range.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="217"></a>217. Facets example (Classifying Japanese characters) contains errors</h3>
-<p><b>Section:</b> 22.2.8 [facets.examples] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-02-29</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facets.examples">issues</a> in [facets.examples].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
-<p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
-must be const in order for it to be callable on a const object (a reference to
-which which is what std::use_facet&lt;&gt;() returns).</p>
-<p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
-name of the namespace `My'.</p>
-<p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
-in main(), the name of the facet is misspelled: it should read `My::JCtype'
-rather than `My::JCType'.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace the "Classifying Japanese characters" example in 22.2.8,
-paragraph 11 with the following:</p>
-<pre>#include &lt;locale&gt;</pre>
-<pre>namespace My {
- using namespace std;
- class JCtype : public locale::facet {
- public:
- static locale::id id; // required for use as a new locale facet
- bool is_kanji (wchar_t c) const;
- JCtype() {}
- protected:
- ~JCtype() {}
- };
-}</pre>
-<pre>// file: filt.C
-#include &lt;iostream&gt;
-#include &lt;locale&gt;
-#include "jctype" // above
-std::locale::id My::JCtype::id; // the static JCtype member
-declared above.</pre>
-<pre>int main()
-{
- using namespace std;
- typedef ctype&lt;wchar_t&gt; wctype;
- locale loc(locale(""), // the user's preferred locale...
- new My::JCtype); // and a new feature ...
- wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
- if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
- cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
- return 0;
-}</pre>
-
-
-
-
-<hr>
-<h3><a name="220"></a>220. ~ios_base() usage valid?</h3>
-<p><b>Section:</b> 27.4.2.7 [ios.base.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 2000-03-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
-paragraph 2:</p>
-<blockquote>
- <p>Effects: Destroys an object of class ios_base. Calls each registered
- callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
- time that any ios_base member function called from within fn has well defined
- results.</p>
-</blockquote>
-<p>But what is not clear is: If no callback functions were ever registered, does
-it matter whether the ios_base members were ever initialized?</p>
-<p>For instance, does this program have defined behavior:</p>
-<blockquote>
- <pre>#include &lt;ios&gt;</pre>
- <pre>class D : public std::ios_base { };</pre>
- <pre>int main() { D d; }</pre>
-</blockquote>
-<p>It seems that registration of a callback function would surely affect the
-state of an ios_base. That is, when you register a callback function with an
-ios_base, the ios_base must record that fact somehow.</p>
-<p>But if after construction the ios_base is in an indeterminate state, and that
-state is not made determinate before the destructor is called, then how would
-the destructor know if any callbacks had indeed been registered? And if the
-number of callbacks that had been registered is indeterminate, then is not the
-behavior of the destructor undefined?</p>
-<p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
-it explicit that destruction before initialization results in undefined
-behavior.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Modify 27.4.2.7 paragraph 1 from</p>
-<blockquote>
- <p>Effects: Each ios_base member has an indeterminate value after
- construction.</p>
-</blockquote>
-<p>to</p>
-<blockquote>
- <p>Effects: Each ios_base member has an indeterminate
-value after construction. These members must be initialized by calling
-basic_ios::init. If an ios_base object is destroyed before these
-initializations have taken place, the behavior is undefined.</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="221"></a>221. num_get&lt;&gt;::do_get stage 2 processing broken</h3>
-<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-03-14</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Stage 2 processing of numeric conversion is broken.</p>
-
-<p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
-conversion specifier is %i. A %i specifier determines a number's base
-by its prefix (0 for octal, 0x for hex), so the intention is clearly
-that a 0x prefix is allowed. Paragraph 8 in the same section,
-however, describes very precisely how characters are processed. (It
-must be done "as if" by a specified code fragment.) That
-description does not allow a 0x prefix to be recognized.</p>
-
-<p>Very roughly, stage 2 processing reads a char_type ct. It converts
-ct to a char, not by using narrow but by looking it up in a
-translation table that was created by widening the string literal
-"0123456789abcdefABCDEF+-". The character "x" is
-not found in that table, so it can't be recognized by stage 2
-processing.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
-<blockquote>
- <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
-</blockquote>
-<p>with the line:</p>
-<blockquote>
- <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>If we're using the technique of widening a string literal, the
-string literal must contain every character we wish to recognize.
-This technique has the consequence that alternate representations
-of digits will not be recognized. This design decision was made
-deliberately, with full knowledge of that limitation.</p>
-
-
-
-
-
-<hr>
-<h3><a name="222"></a>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3>
-<p><b>Section:</b> 17.3.1.3 [structure.specifications] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-03-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
-<blockquote>
- <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
-
-int compare(size_type pos1, size_type n1,
- const basic_string&lt;charT,traits,Allocator&gt;&amp; str ,
- size_type pos2 , size_type n2 ) const;
-
--4- Returns:
-
- basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
- basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
-</blockquote>
-<p>and the constructor that's implicitly called by the above is
-defined to throw an out-of-range exception if pos &gt; str.size(). See
-section 21.3.1 [string.require] paragraph 4.</p>
-
-<p>On the other hand, the compare function descriptions themselves don't have
-"Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
-that do not apply to a function are omitted.</p>
-<p>So it seems there is an inconsistency in the standard -- are the
-"Effects" clauses correct, or are the "Throws" clauses
-missing?</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 17.3.1.3 [structure.specifications] paragraph 3, the footnote 148 attached to
-the sentence "Descriptions of function semantics contain the
-following elements (as appropriate):", insert the word
-"further" so that the foot note reads:</p>
-<blockquote>
- <p>To save space, items that do not apply to a function are
- omitted. For example, if a function does not specify any further
- preconditions, there will be no "Requires" paragraph.</p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>The standard is somewhat inconsistent, but a failure to note a
-throw condition in a throws clause does not grant permission not to
-throw. The inconsistent wording is in a footnote, and thus
-non-normative. The proposed resolution from the LWG clarifies the
-footnote.</p>
-
-
-
-
-<hr>
-<h3><a name="223"></a>223. reverse algorithm should use iter_swap rather than swap</h3>
-<p><b>Section:</b> 25.2.10 [alg.reverse] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-03-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 25.2.10 [alg.reverse], replace:</p>
- <blockquote><p>
- Effects: For each non-negative integer i &lt;= (last - first)/2,
- applies swap to all pairs of iterators first + i, (last - i) - 1.
- </p></blockquote>
-<p>with:</p>
- <blockquote><p>
- Effects: For each non-negative integer i &lt;= (last - first)/2,
- applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
- </p></blockquote>
-
-
-
-
-<hr>
-<h3><a name="224"></a>224. clear() complexity for associative containers refers to undefined N</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Ed Brey <b>Date:</b> 2000-03-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In the associative container requirements table in 23.1.2 paragraph 7,
-a.clear() has complexity "log(size()) + N". However, the meaning of N
-is not defined.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In the associative container requirements table in 23.1.2 paragraph
-7, the complexity of a.clear(), change "log(size()) + N" to
-"linear in <tt>size()</tt>".</p>
-
-
-<p><b>Rationale:</b></p>
-<p>It's the "log(size())", not the "N", that is in
-error: there's no difference between <i>O(N)</i> and <i>O(N +
-log(N))</i>. The text in the standard is probably an incorrect
-cut-and-paste from the range version of <tt>erase</tt>.</p>
-
-
-
-
-<hr>
-<h3><a name="225"></a>225. std:: algorithms use of other unqualified algorithms</h3>
-<p><b>Section:</b> 17.4.4.3 [global.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#global.functions">issues</a> in [global.functions].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
-user namespaces might be found through Koenig lookup?</p>
-<p>For example, a popular standard library implementation includes this
-implementation of std::unique:</p>
-<blockquote>
-<pre>namespace std {
- template &lt;class _ForwardIter&gt;
- _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
- __first = adjacent_find(__first, __last);
- return unique_copy(__first, __last, __first);
- }
- }</pre>
-</blockquote>
-<p>Imagine two users on opposite sides of town, each using unique on his own
-sequences bounded by my_iterators . User1 looks at his standard library
-implementation and says, "I know how to implement a more efficient
-unique_copy for my_iterators", and writes:</p>
-<blockquote>
-<pre>namespace user1 {
- class my_iterator;
- // faster version for my_iterator
- my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
- }</pre>
-</blockquote>
-<p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
-<p>User2 has other needs, and writes:</p>
-<blockquote>
-<pre>namespace user2 {
- class my_iterator;
- // Returns true iff *c is a unique copy of *a and *b.
- bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
- }</pre>
-</blockquote>
-<p>User2 is shocked to find later that his fully-qualified use of
-std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
-compile (if he's lucky). Looking in the standard, he sees the following Effects
-clause for unique():</p>
-<blockquote>
- <p>Effects: Eliminates all but the first element from every consecutive group
- of equal elements referred to by the iterator i in the range [first, last) for
- which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
- *(i - 1)) != false</p>
-</blockquote>
-<p>The standard gives user2 absolutely no reason to think he can interfere with
-std::unique by defining names in namespace user2. His standard library has been
-built with the template export feature, so he is unable to inspect the
-implementation. User1 eventually compiles his code with another compiler, and
-his version of unique_copy silently stops being called. Eventually, he realizes
-that he was depending on an implementation detail of his library and had no
-right to expect his unique_copy() to be called portably.</p>
-<p>On the face of it, and given above scenario, it may seem obvious that the
-implementation of unique() shown is non-conforming because it uses unique_copy()
-rather than ::std::unique_copy(). Most standard library implementations,
-however, seem to disagree with this notion.</p>
-<p> <i>[Tokyo:&nbsp; Steve Adamczyk from
-the core working group indicates that "std::" is sufficient;&nbsp;
-leading "::" qualification is not required because any namespace
-qualification is sufficient to suppress Koenig lookup.]</i></p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add a paragraph and a note at the end of
-17.4.4.3 [global.functions]:</p>
-<blockquote>
-
-<p>Unless otherwise specified, no global or non-member function in the
-standard library shall use a function from another namespace which is
-found through <i>argument-dependent name lookup</i> (3.4.2 [basic.lookup.argdep]).</p>
-
-<p>[Note: the phrase "unless otherwise specified" is intended to
-allow Koenig lookup in cases like that of ostream_iterators:<br>
-
-<br>
- Effects:</p>
- <blockquote>
-<p>*out_stream &lt;&lt; value;<br>
- if(delim != 0) *out_stream &lt;&lt; delim;<br>
- return (*this);</p>
- <p>--end note]</p>
- </blockquote>
-</blockquote>
-
-<p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
-is as yet unsure if the proposed resolution is the best
-solution. Furthermore, the LWG believes that the same problem of
-unqualified library names applies to wording in the standard itself,
-and has opened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> accordingly. Any resolution of
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be coordinated with the resolution of
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
-
-
-<p><i>[Toronto: The LWG is not sure if this is a defect in the
-standard. Most LWG members believe that an implementation of
-<tt>std::unique</tt> like the one quoted in this issue is already
-illegal, since, under certain circumstances, its semantics are not
-those specified in the standard. The standard's description of
-<tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
-should have any effect.]</i></p>
-
-
-<p><i>[Curaao: An LWG-subgroup spent an afternoon working on issues
-225, 226, and 229. Their conclusion was that the issues should be
-separated into an LWG portion (Howard's paper, N1387=02-0045), and a
-EWG portion (Dave will write a proposal). The LWG and EWG had
-(separate) discussions of this plan the next day. The proposed
-resolution for this issue is in accordance with Howard's paper.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>It could be argued that this proposed isn't strictly necessary,
- that the Standard doesn't grant implementors license to write a
- standard function that behaves differently than specified in the
- Standard just because of an unrelated user-defined name in some
- other namespace. However, this is at worst a clarification. It is
- surely right that algorithsm shouldn't pick up random names, that
- user-defined names should have no effect unless otherwise specified.
- Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> deals with the question of when it is
- appropriate for the standard to explicitly specify otherwise.</p>
-
-
-
-
-
-<hr>
-<h3><a name="226"></a>226. User supplied specializations or overloads of namespace std function templates</h3>
-<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The issues are:&nbsp;</p>
-<p>1. How can a 3rd party library implementor (lib1) write a version of a standard
-algorithm which is specialized to work with his own class template?&nbsp;</p>
-<p>2. How can another library implementor (lib2) write a generic algorithm which
-will take advantage of the specialized algorithm in lib1?</p>
-<p>This appears to be the only viable answer under current language rules:</p>
-<blockquote>
- <pre>namespace lib1
-{
- // arbitrary-precision numbers using T as a basic unit
- template &lt;class T&gt;
- class big_num { //...
- };
- </pre>
- <pre> // defining this in namespace std is illegal (it would be an
- // overload), so we hope users will rely on Koenig lookup
- template &lt;class T&gt;
- void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
-}</pre>
- <pre>#include &lt;algorithm&gt;
-namespace lib2
-{
- template &lt;class T&gt;
- void generic_sort(T* start, T* end)
- {
- ...
- // using-declaration required so we can work on built-in types
- using std::swap;
- // use Koenig lookup to find specialized algorithm if available
- swap(*x, *y);
- }
-}</pre>
-</blockquote>
-<p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
-and somewhat slippery. The implementor needs to remember to write the
-using-declaration, or generic_sort will fail to compile when T is a built-in
-type. The second drawback is that the use of this style in lib2 effectively
-"reserves" names in any namespace which defines types which may
-eventually be used with lib2. This may seem innocuous at first when applied to
-names like swap, but consider more ambiguous names like unique_copy() instead.
-It is easy to imagine the user wanting to define these names differently in his
-own namespace. A definition with semantics incompatible with the standard
-library could cause serious problems (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>).</p>
-<p>Why, you may ask, can't we just partially specialize std::swap()? It's
-because the language doesn't allow for partial specialization of function
-templates. If you write:</p>
-<blockquote>
- <pre>namespace std
-{
- template &lt;class T&gt;
- void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
-}</pre>
-</blockquote>
-<p>You have just overloaded std::swap, which is illegal under the current
-language rules. On the other hand, the following full specialization is legal:</p>
-<blockquote>
- <pre>namespace std
-{
- template &lt;&gt;
- void swap(lib1::other_type&amp;, lib1::other_type&amp;);
-}</pre>
-</blockquote>
-
-<p>This issue reflects concerns raised by the "Namespace issue
-with specialized swap" thread on comp.lang.c++.moderated. A
-similar set of concerns was earlier raised on the boost.org mailing
-list and the ACCU-general mailing list. Also see library reflector
-message c++std-lib-7354.</p>
-
-<p>
-J. C. van Winkel points out (in c++std-lib-9565) another unexpected
-fact: it's impossible to output a container of std::pair's using copy
-and an ostream_iterator, as long as both pair-members are built-in or
-std:: types. That's because a user-defined operator&lt;&lt; for (for
-example) std::pair&lt;const std::string, int&gt; will not be found:
-lookup for operator&lt;&lt; will be performed only in namespace std.
-Opinions differed on whether or not this was a defect, and, if so,
-whether the defect is that something is wrong with user-defined
-functionality and std, or whether it's that the standard library does
-not provide an operator&lt;&lt; for std::pair&lt;&gt;.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Adopt the wording proposed in Howard Hinnant's paper
- N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
-
-
-<p><i>[Tokyo: Summary, "There is no conforming way to extend
-std::swap for user defined templates."&nbsp; The LWG agrees that
-there is a problem. Would like more information before
-proceeding. This may be a core issue. Core issue 229 has been opened
-to discuss the core aspects of this problem. It was also noted that
-submissions regarding this issue have been received from several
-sources, but too late to be integrated into the issues list.
-]</i></p>
-
-
-<p><i>[Post-Tokyo: A paper with several proposed resolutions,
-J16/00-0029==WG21/N1252, "Shades of namespace std functions
-" by Alan Griffiths, is in the Post-Tokyo mailing. It
-should be considered a part of this issue.]</i></p>
-
-
-<p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
-resolution that involves core changes: it would add partial
-specialization of function template. The Core Working Group is
-reluctant to add partial specialization of function templates. It is
-viewed as a large change, CWG believes that proposal presented leaves
-some syntactic issues unanswered; if the CWG does add partial
-specialization of function templates, it wishes to develop its own
-proposal. The LWG continues to believe that there is a serious
-problem: there is no good way for users to force the library to use
-user specializations of generic standard library functions, and in
-certain cases (e.g. transcendental functions called by
-<tt>valarray</tt> and <tt>complex</tt>) this is important. Koenig
-lookup isn't adequate, since names within the library must be
-qualified with <tt>std</tt> (see issue 225), specialization doesn't
-work (we don't have partial specialization of function templates), and
-users aren't permitted to add overloads within namespace std.
-]</i></p>
-
-
-<p><i>[Copenhagen: Discussed at length, with no consensus. Relevant
-papers in the pre-Copenhagen mailing: N1289, N1295, N1296. Discussion
-focused on four options. (1) Relax restrictions on overloads within
-namespace std. (2) Mandate that the standard library use unqualified
-calls for <tt>swap</tt> and possibly other functions. (3) Introduce
-helper class templates for <tt>swap</tt> and possibly other functions.
-(4) Introduce partial specialization of function templates. Every
-option had both support and opposition. Straw poll (first number is
-support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
-(4) 4, 4.]</i></p>
-
-
-<p><i>[Redmond: Discussed, again no consensus. Herb presented an
-argument that a user who is defining a type <tt>T</tt> with an
-associated <tt>swap</tt> should not be expected to put that
-<tt>swap</tt> in namespace std, either by overloading or by partial
-specialization. The argument is that <tt>swap</tt> is part of
-<tt>T</tt>'s interface, and thus should to in the same namespace as
-<tt>T</tt> and only in that namespace. If we accept this argument,
-the consequence is that standard library functions should use
-unqualified call of <tt>swap</tt>. (And which other functions? Any?)
-A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
-try to put together a proposal before the next meeting.]</i></p>
-
-
-<p><i>[Curaao: An LWG-subgroup spent an afternoon working on issues
-225, 226, and 229. Their conclusion was that the issues should be
-separated into an LWG portion (Howard's paper, N1387=02-0045), and a
-EWG portion (Dave will write a proposal). The LWG and EWG had
-(separate) discussions of this plan the next day. The proposed
-resolution is the one proposed by Howard.]</i></p>
-
-
-<p><i>[Santa Cruz: the LWG agreed with the general direction of
- Howard's paper, N1387. (Roughly: Koenig lookup is disabled unless
- we say otherwise; this issue is about when we do say otherwise.)
- However, there were concerns about wording. Howard will provide new
- wording. Bill and Jeremy will review it.]</i></p>
-
-
-<p><i>[Kona: Howard proposed the new wording. The LWG accepted his
- proposed resolution.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>Informally: introduce a Swappable concept, and specify that the
- value types of the iterators passed to certain standard algorithms
- (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
- to that concept. The Swappable concept will make it clear that
- these algorithms use unqualified lookup for the calls
- to <tt>swap</tt>. Also, in 26.5.3.3 [valarray.transcend] paragraph 1,
- state that the valarray transcendentals use unqualified lookup.</p>
-
-
-
-
-
-<hr>
-<h3><a name="227"></a>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3>
-<p><b>Section:</b> 25.2.3 [alg.swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-04-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.swap">issues</a> in [alg.swap].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TC">TC</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>25.2.2 reads:</p>
-<blockquote>
- <p><tt> template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
- <br>
- Requires: Type T is Assignable (_lib.container.requirements_).<br>
- Effects: Exchanges values stored in two locations.</p>
-</blockquote>
-<p>The only reasonable** generic implementation of swap requires construction of a
- new temporary copy of one of its arguments:</p>
-<blockquote>
-<pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
- {
- T tmp(a);
- a = b;
- b = tmp;
- }</pre>
-</blockquote>
-<p>But a type which is only Assignable cannot be swapped by this implementation.</p>
-<p>**Yes, there's also an unreasonable implementation which would require T to be
- DefaultConstructible instead of CopyConstructible. I don't think this is worthy
- of consideration:</p>
-<blockquote>
-<pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
-{
- T tmp;
- tmp = a;
- a = b;
- b = tmp;
-}</pre>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 25.2.2 paragraph 1 from:</p>
-<blockquote>
-<p> Requires: Type T is Assignable (23.1).</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
-<p> Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="228"></a>228. Incorrect specification of "..._byname" facets</h3>
-<p><b>Section:</b> 22.2 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 2000-04-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The sections 22.2.1.2 [locale.ctype.byname], 22.2.1.5
-[locale.codecvt.byname],
-sref ref="22.2.1.6", 22.2.3.2 [locale.numpunct.byname], 22.2.4.2
-[locale.collate.byname], 22.2.5.4 [locale.time.put.byname], 22.2.6.4
-[locale.moneypunct.byname], and 22.2.7.2 [locale.messages.byname]
-overspecify the
-definitions of the "..._byname" classes by listing a bunch
-of virtual functions. At the same time, no semantics of these
-functions are defined. Real implementations do not define these
-functions because the functional part of the facets is actually
-implemented in the corresponding base classes and the constructor of
-the "..._byname" version just provides suitable date used by
-these implementations. For example, the 'numpunct' methods just return
-values from a struct. The base class uses a statically initialized
-struct while the derived version reads the contents of this struct
-from a table. However, no virtual function is defined in
-'numpunct_byname'.</p>
-
-<p>For most classes this does not impose a problem but specifically
-for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
-is required because otherwise the semantics would change due to the
-virtual functions defined in the general version for 'ctype_byname':
-In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
-made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
-Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
-this class is specialized or not under the current specification:
-Without the specialization, 'do_is()' is virtual while with
-specialization it is not virtual.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
-<pre> namespace std {
- template &lt;class charT&gt;
- class ctype_byname : public ctype&lt;charT&gt; {
- public:
- typedef ctype&lt;charT&gt;::mask mask;
- explicit ctype_byname(const char*, size_t refs = 0);
- protected:
- ~ctype_byname(); // virtual
- };
- }</pre>
-<p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
-<pre> namespace std {
- template &lt;class internT, class externT, class stateT&gt;
- class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
- public:
- explicit codecvt_byname(const char*, size_t refs = 0);
- protected:
- ~codecvt_byname(); // virtual
- };
- }
-</pre>
-<p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
-<pre> namespace std {
- template &lt;class charT&gt;
- class numpunct_byname : public numpunct&lt;charT&gt; {
- // this class is specialized for char and wchar_t.
- public:
- typedef charT char_type;
- typedef basic_string&lt;charT&gt; string_type;
- explicit numpunct_byname(const char*, size_t refs = 0);
- protected:
- ~numpunct_byname(); // virtual
- };
- }</pre>
-<p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
-<pre> namespace std {
- template &lt;class charT&gt;
- class collate_byname : public collate&lt;charT&gt; {
- public:
- typedef basic_string&lt;charT&gt; string_type;
- explicit collate_byname(const char*, size_t refs = 0);
- protected:
- ~collate_byname(); // virtual
- };
- }</pre>
-<p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
-<pre> namespace std {
- template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
- class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
- public:
- typedef time_base::dateorder dateorder;
- typedef InputIterator iter_type</pre>
-<pre> explicit time_get_byname(const char*, size_t refs = 0);
- protected:
- ~time_get_byname(); // virtual
- };
- }</pre>
-<p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
-<pre> namespace std {
- template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
- class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
- {
- public:
- typedef charT char_type;
- typedef OutputIterator iter_type;</pre>
-<pre> explicit time_put_byname(const char*, size_t refs = 0);
- protected:
- ~time_put_byname(); // virtual
- };
- }"</pre>
-<p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
-<pre> namespace std {
- template &lt;class charT, bool Intl = false&gt;
- class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
- public:
- typedef money_base::pattern pattern;
- typedef basic_string&lt;charT&gt; string_type;</pre>
-<pre> explicit moneypunct_byname(const char*, size_t refs = 0);
- protected:
- ~moneypunct_byname(); // virtual
- };
- }</pre>
-<p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
-<pre> namespace std {
- template &lt;class charT&gt;
- class messages_byname : public messages&lt;charT&gt; {
- public:
- typedef messages_base::catalog catalog;
- typedef basic_string&lt;charT&gt; string_type;</pre>
-<pre> explicit messages_byname(const char*, size_t refs = 0);
- protected:
- ~messages_byname(); // virtual
- };
- }</pre>
-<p>Remove section 22.2.1.4 [locale.codecvt] completely (because in
-this case only those members are defined to be virtual which are
-defined to be virtual in 'ctype&lt;cT&gt;'.)</p>
-
-<p><i>[Post-Tokyo: Dietmar Khl submitted this issue at the request of
-the LWG to solve the underlying problems raised by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>.]</i></p>
-
-
-<p><i>[Copenhagen: proposed resolution was revised slightly, to remove
-three last virtual functions from <tt>messages_byname</tt>.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="229"></a>229. Unqualified references of other library entities</h3>
-<p><b>Section:</b> 17.4.1.1 [contents] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 2000-04-19</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Throughout the library chapters, the descriptions of library entities refer
-to other library entities without necessarily qualifying the names.</p>
-
-<p>For example, section 25.2.2 "Swap" describes the effect of
-swap_ranges in terms of the unqualified name "swap". This section
-could reasonably be interpreted to mean that the library must be implemented so
-as to do a lookup of the unqualified name "swap", allowing users to
-override any ::std::swap function when Koenig lookup applies.</p>
-
-<p>Although it would have been best to use explicit qualification with
-"::std::" throughout, too many lines in the standard would have to be
-adjusted to make that change in a Technical Corrigendum.</p>
-
-<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
-<tt>size_t</tt>, is a special case of this.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
-<blockquote>
- <p>Whenever a name x defined in the standard library is mentioned, the name x
- is assumed to be fully qualified as ::std::x, unless explicitly described
- otherwise. For example, if the Effects section for library function F is
- described as calling library function G, the function ::std::G is meant.</p>
-</blockquote>
-
-<p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
-the LWG to solve a problem in the standard itself similar to the
-problem within implementations of library identified by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>. Any resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be
-coordinated with the resolution of this issue.]</i></p>
-
-
-<p><i>[post-Toronto: Howard is undecided about whether it is
-appropriate for all standard library function names referred to in
-other standard library functions to be explicitly qualified by
-<tt>std</tt>: it is common advice that users should define global
-functions that operate on their class in the same namespace as the
-class, and this requires argument-dependent lookup if those functions
-are intended to be called by library code. Several LWG members are
-concerned that valarray appears to require argument-dependent lookup,
-but that the wording may not be clear enough to fall under
-"unless explicitly described otherwise".]</i></p>
-
-
-<p><i>[Curaao: An LWG-subgroup spent an afternoon working on issues
-225, 226, and 229. Their conclusion was that the issues should be
-separated into an LWG portion (Howard's paper, N1387=02-0045), and a
-EWG portion (Dave will write a proposal). The LWG and EWG had
-(separate) discussions of this plan the next day. This paper resolves
-issues 225 and 226. In light of that resolution, the proposed
-resolution for the current issue makes sense.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="230"></a>230. Assignable specified without also specifying CopyConstructible</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2000-04-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> identified an instance (std::swap) where
-Assignable was specified without also specifying
-CopyConstructible. The LWG asked that the standard be searched to
-determine if the same defect existed elsewhere.</p>
-
-<p>There are a number of places (see proposed resolution below) where
-Assignable is specified without also specifying
-CopyConstructible. There are also several cases where both are
-specified. For example, 26.4.1 [rand.req].</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 23.1 [container.requirements] table 65 for value_type:
-change "T is Assignable" to "T is CopyConstructible and
-Assignable"
-</p>
-
-<p>In 23.1.4 [associative.reqmts] table 69 X::key_type; change
-"Key is Assignable" to "Key is
-CopyConstructible and Assignable"<br>
-</p>
-
-<p>In 24.1.2 [output.iterators] paragraph 1, change:
-</p>
-<blockquote>
-<p> A class or a built-in type X satisfies the requirements of an
-output iterator if X is an Assignable type (23.1) and also the
-following expressions are valid, as shown in Table 73:
-</p>
-</blockquote>
-<p>to:
-</p>
-<blockquote>
-<p> A class or a built-in type X satisfies the requirements of an
-output iterator if X is a CopyConstructible (20.1.3) and Assignable
-type (23.1) and also the following expressions are valid, as shown in
-Table 73:
-</p>
-</blockquote>
-
-<p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
-the LWG. He asks that the 25.2.5 [alg.replace] and 25.2.6 [alg.fill] changes be studied carefully, as it is not clear that
-CopyConstructible is really a requirement and may be
-overspecification.]</i></p>
-
-
-<p><i>[Portions of the resolution for issue 230 have been superceded by
-the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The original proposed resolution also included changes to input
-iterator, fill, and replace. The LWG believes that those changes are
-not necessary. The LWG considered some blanket statement, where an
-Assignable type was also required to be Copy Constructible, but
-decided against this because fill and replace really don't require the
-Copy Constructible property.</p>
-
-
-
-
-<hr>
-<h3><a name="231"></a>231. Precision in iostream?</h3>
-<p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> James Kanze, Stephen Clamage <b>Date:</b> 2000-04-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>What is the following program supposed to output?</p>
-<pre>#include &lt;iostream&gt;
-
- int
- main()
- {
- std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
- std::cout.precision( 0 ) ;
- std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
- return 0 ;
- }</pre>
-<p>From my C experience, I would expect "1e+00"; this is what
-<tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
-"1.000000e+00".</p>
-
-<p>The only indication I can find in the standard is 22.2.2.2.2/11,
-where it says "For conversion from a floating-point type, if
-(flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
-str.precision() is specified in the conversion specification."
-This is an obvious error, however, fixed is not a mask for a field,
-but a value that a multi-bit field may take -- the results of and'ing
-fmtflags with ios::fixed are not defined, at least not if
-ios::scientific has been set. G++'s behavior corresponds to what might
-happen if you do use (flags &amp; fixed) != 0 with a typical
-implementation (floatfield == 3 &lt;&lt; something, fixed == 1
-&lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
-
-<p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
-(flags &amp; floatfield) == fixed; the first gives something more or
-less like the effect of precision in a printf floating point
-conversion. Only more or less, of course. In order to implement printf
-formatting correctly, you must know whether the precision was
-explicitly set or not. Say by initializing it to -1, instead of 6, and
-stating that for floating point conversions, if precision &lt; -1, 6
-will be used, for fixed point, if precision &lt; -1, 1 will be used,
-etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
-0, 1 should be = used. But it probably isn't necessary to emulate all
-of the anomalies of printf:-).</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Replace 22.2.2.2.2 [facet.num.put.virtuals], paragraph 11, with the following
-sentence:
-</p>
-<blockquote><p>
-For conversion from a floating-point type,
-<tt><i>str</i>.precision()</tt> is specified in the conversion
-specification.
-</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>The floatfield determines whether numbers are formatted as if
-with %f, %e, or %g. If the <tt>fixed</tt> bit is set, it's %f,
-if <tt>scientific</tt> it's %e, and if both bits are set, or
-neither, it's %g.</p>
-<p>Turning to the C standard, a precision of 0 is meaningful
-for %f and %e. For %g, precision 0 is taken to be the same as
-precision 1.</p>
-<p>The proposed resolution has the effect that if neither
-<tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
-specifying a precision of 0, which will be internally
-turned into 1. There's no need to call it out as a special
-case.</p>
-<p>The output of the above program will be "1e+00".</p>
-
-<p><i>[Post-Curaao: Howard provided improved wording covering the case
-where precision is 0 and mode is %g.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="232"></a>232. "depends" poorly defined in 17.4.3.1</h3>
-<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2000-04-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
-specializations of standard templates to those that "depend on a
-user-defined name of external linkage."</p>
-<p>This term, however, is not adequately defined, making it possible to
-construct a specialization that is, I believe, technically legal according to
-17.4.3.1/1, but that specializes a standard template for a built-in type such as
-'int'.</p>
-<p>The following code demonstrates the problem:</p>
-<blockquote>
- <pre>#include &lt;algorithm&gt;</pre>
- <pre>template&lt;class T&gt; struct X
-{
- typedef T type;
-};</pre>
- <pre>namespace std
-{
- template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
-}</pre>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change "user-defined name" to "user-defined
-type".</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
-Programming Language</i>. It disallows the example in the issue,
-since the underlying type itself is not user-defined. The only
-possible problem I can see is for non-type templates, but there's no
-possible way for a user to come up with a specialization for bitset,
-for example, that might not have already been specialized by the
-implementor?</p>
-
-<p><i>[Toronto: this may be related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>.]</i></p>
-
-
-<p><i>[post-Toronto: Judy provided the above proposed resolution and
-rationale.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="233"></a>233. Insertion hints in associative containers</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andrew Koenig <b>Date:</b> 2000-04-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#192">192</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#246">246</a></p>
-<p><b>Discussion:</b></p>
-<p>
-If <tt>mm</tt> is a multimap and <tt>p</tt> is an iterator
-into the multimap, then <tt>mm.insert(p, x)</tt> inserts
-<tt>x</tt> into <tt>mm</tt> with <tt>p</tt> as a hint as
-to where it should go. Table 69 claims that the execution time is
-amortized constant if the insert winds up taking place adjacent to
-<tt>p</tt>, but does not say when, if ever, this is guaranteed to
-happen. All it says it that <tt>p</tt> is a hint as to where to
-insert.
-</p>
-<p>
-The question is whether there is any guarantee about the relationship
-between <tt>p</tt> and the insertion point, and, if so, what it
-is.
-</p>
-<p>
-I believe the present state is that there is no guarantee: The user
-can supply <tt>p</tt>, and the implementation is allowed to
-disregard it entirely.
-</p>
-
-<p><b>Additional comments from Nathan:</b><br>
-
-The vote [in Redmond] was on whether to elaborately specify the use of
-the hint, or to require behavior only if the value could be inserted
-adjacent to the hint. I would like to ensure that we have a chance to
-vote for a deterministic treatment: "before, if possible, otherwise
-after, otherwise anywhere appropriate", as an alternative to the
-proposed "before or after, if possible, otherwise [...]".
-</p>
-
-<p><i>[Toronto: there was general agreement that this is a real defect:
-when inserting an element x into a multiset that already contains
-several copies of x, there is no way to know whether the hint will be
-used. The proposed resolution was that the new element should always
-be inserted as close to the hint as possible. So, for example, if
-there is a subsequence of equivalent values, then providing a.begin()
-as the hint means that the new element should be inserted before the
-subsequence even if a.begin() is far away. JC van Winkel supplied
-precise wording for this proposed resolution, and also for an
-alternative resolution in which hints are only used when they are
-adjacent to the insertion point.]</i></p>
-
-
-<p><i>[Copenhagen: the LWG agreed to the original proposed resolution,
-in which an insertion hint would be used even when it is far from the
-insertion point. This was contingent on seeing a example
-implementation showing that it is possible to implement this
-requirement without loss of efficiency. John Potter provided such a
-example implementation.]</i></p>
-
-
-<p><i>[Redmond: The LWG was reluctant to adopt the proposal that
-emerged from Copenhagen: it seemed excessively complicated, and went
-beyond fixing the defect that we identified in Toronto. PJP provided
-the new wording described in this issue. Nathan agrees that we
-shouldn't adopt the more detailed semantics, and notes: "we know that
-you can do it efficiently enough with a red-black tree, but there are
-other (perhaps better) balanced tree techniques that might differ
-enough to make the detailed semantics hard to satisfy."]</i></p>
-
-
-<p><i>[Curaao: Nathan should give us the alternative wording he
-suggests so the LWG can decide between the two options.]</i></p>
-
-
-<p><i>[Lillehammer: The LWG previously rejected the more detailed
- semantics, because it seemed more loike a new feature than like
- defect fixing. We're now more sympathetic to it, but we (especially
- Bill) are still worried about performance. N1780 describes a naive
- algorithm, but it's not clear whether there is a non-naive
- implementation. Is it possible to implement this as efficently as
- the current version of insert?]</i></p>
-
-
-<p><i>[Post Lillehammer:
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">N1780</a>
-updated in post meeting mailing with
-feedback from Lillehammer with more information regarding performance.
-]</i></p>
-
-
-<p><i>[
-Batavia:
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
-accepted with minor wording changes in the proposed wording (reflected in the
-proposed resolution below). Concerns about the performance of the algorithm
-were satisfactorily met by
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>.
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a> already handles the stability of equal ranges
-and so that part of the resolution from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html">1780</a>
-is no longer needed (or reflected in the proposed wording below).
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change the indicated rows of the "Associative container requirements" Table in
-23.1.4 [associative.reqmts] to:
-</p>
-
-<p></p><center>
-<table border="1">
-<caption>Associative container requirements</caption>
-<tbody><tr><th>expression</th> <th>return type</th>
-<th>assertion/note<br>pre/post-condition</th>
-<th>complexity</th></tr>
-<tr><td><tt>a_eq.insert(t)</tt></td>
-<td><tt>iterator</tt></td>
-<td>
-inserts <tt>t</tt> and returns the iterator pointing to the newly inserted
-element. <ins>If a range containing elements equivalent to <tt>t</tt> exists in
-<tt>a_eq</tt>, <tt>t</tt> is inserted at the end of that range.</ins>
-</td>
-<td>
-logarithmic
-</td></tr>
-<tr><td><tt>a.insert(p,t)</tt></td>
-<td><tt>iterator</tt></td>
-<td>
-inserts <tt>t</tt> if and only if there is no element with key equivalent to the
-key of <tt>t</tt> in containers with unique keys; always inserts <tt>t</tt> in containers
-with equivalent keys. always returns the iterator pointing to the element with key
-equivalent to the key of <tt>t</tt>. <del>iterator <tt>p</tt> is a hint pointing to where
-the insert should start to search.</del> <ins><tt>t</tt> is inserted as close as possible
-to the position just prior to <tt>p</tt>.</ins>
-</td>
-<td>
-logarithmic in general, but amortized constant if <tt>t</tt> is inserted right <del>after</del>
- <ins>before</ins> <tt>p</tt>.
-</td></tr>
-</tbody></table>
-</center>
-
-
-
-
-
-
-<hr>
-<h3><a name="234"></a>234. Typos in allocator definition</h3>
-<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 2000-04-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
-<tt>destruct()</tt> are described as returns but the functions actually
-return <tt>void</tt>.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Substitute "Returns" by "Effect".</p>
-
-
-
-
-<hr>
-<h3><a name="235"></a>235. No specification of default ctor for reverse_iterator</h3>
-<p><b>Section:</b> 24.4.1.1 [reverse.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 2000-04-24</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The declaration of <tt>reverse_iterator</tt> lists a default
-constructor. However, no specification is given what this constructor
-should do.</p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>In section 24.4.1.3.1 [reverse.iter.cons] add the following
- paragraph:</p>
- <blockquote>
- <p><tt>reverse_iterator()</tt></p>
-
- <p>Default initializes <tt>current</tt>. Iterator operations
- applied to the resulting iterator have defined behavior if and
- only if the corresponding operations are defined on a default
- constructed iterator of type <tt>Iterator</tt>.</p>
- </blockquote>
- <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
- resolution.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="237"></a>237. Undefined expression in complexity specification</h3>
-<p><b>Section:</b> 23.2.2.1 [deque.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 2000-04-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#deque.cons">issues</a> in [deque.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The complexity specification in paragraph 6 says that the complexity
-is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
-defined on iterators this term is in general undefined because it
-would have to be <tt>last - first</tt>.</p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>Change paragraph 6 from</p>
- <blockquote><p>Linear in <i>first - last</i>.</p></blockquote>
- <p>to become</p>
- <blockquote><p>Linear in <i>distance(first, last)</i>.</p></blockquote>
-
-
-
-
-<hr>
-<h3><a name="238"></a>238. Contradictory results of stringbuf initialization.</h3>
-<p><b>Section:</b> 27.7.1.1 [stringbuf.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dietmar Khl <b>Date:</b> 2000-05-11</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
-'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
-that far but consider this code:</p>
-
-<pre> std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
- std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
-</pre>
-
-<p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
-the output sequence nor the input sequence is initialized and
-paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
-returns the input or the output sequence. None of them is initialized,
-ie. both are empty, in which case the return from <tt>str()</tt> is
-defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
-
-<p>However, probably only test cases in some testsuites will detect this
-"problem"...</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Remove 27.7.1.1 paragraph 4.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>We could fix 27.7.1.1 paragraph 4, but there would be no point. If
-we fixed it, it would say just the same thing as text that's already
-in the standard.</p>
-
-
-
-
-<hr>
-<h3><a name="239"></a>239. Complexity of unique() and/or unique_copy incorrect</h3>
-<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The complexity of unique and unique_copy are inconsistent with each
-other and inconsistent with the implementations.&nbsp; The standard
-specifies:</p>
-
-<p>for unique():</p>
-
-<blockquote><p>-3- Complexity: If the range (last - first) is not empty, exactly
-(last - first) - 1 applications of the corresponding predicate, otherwise
-no applications of the predicate.</p></blockquote>
-
-<p>for unique_copy():</p>
-
-<blockquote><p>-7- Complexity: Exactly last - first applications of the corresponding
-predicate.</p></blockquote>
-
-<p>
-The implementations do it the other way round: unique() applies the
-predicate last-first times and unique_copy() applies it last-first-1
-times.</p>
-
-<p>As both algorithms use the predicate for pair-wise comparison of
-sequence elements I don't see a justification for unique_copy()
-applying the predicate last-first times, especially since it is not
-specified to which pair in the sequence the predicate is applied
-twice.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change both complexity sections in 25.2.9 [alg.unique] to:</p>
-
-<blockquote><p>Complexity: For nonempty ranges, exactly last - first - 1
-applications of the corresponding predicate.</p></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="240"></a>240. Complexity of adjacent_find() is meaningless</h3>
-<p><b>Section:</b> 25.1.8 [alg.adjacent.find] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The complexity section of adjacent_find is defective:</p>
-
-<blockquote>
-<pre>template &lt;class ForwardIterator&gt;
-ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
- BinaryPredicate pred);
-</pre>
-
-<p>-1- Returns: The first iterator i such that both i and i + 1 are in
-the range [first, last) for which the following corresponding
-conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
-last if no such iterator is found.</p>
-
-<p>-2- Complexity: Exactly find(first, last, value) - first applications
-of the corresponding predicate.
-</p>
-</blockquote>
-
-<p>In the Complexity section, it is not defined what "value"
-is supposed to mean. My best guess is that "value" means an
-object for which one of the conditions pred(*i,value) or
-pred(value,*i) is true, where i is the iterator defined in the Returns
-section. However, the value type of the input sequence need not be
-equality-comparable and for this reason the term find(first, last,
-value) - first is meaningless.</p>
-
-<p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
-find_if(first, last, bind1st(pred,*i)) - first might come closer to
-the intended specification. Binders can only be applied to function
-objects that have the function call operator declared const, which is
-not required of predicates because they can have non-const data
-members. For this reason, a specification using a binder could only be
-an "as-if" specification.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the complexity section in 25.1.8 [alg.adjacent.find] to:</p>
-<blockquote><p>
-For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
-(<i>last</i> - <i>first</i>) - 1)</tt> applications of the
-corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
-return value.
-</p></blockquote>
-
-<p><i>[Copenhagen: the original resolution specified an upper
-bound. The LWG preferred an exact count.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="241"></a>241. Does unique_copy() require CopyConstructible and Assignable?</h3>
-<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>Some popular implementations of unique_copy() create temporary
-copies of values in the input sequence, at least if the input iterator
-is a pointer. Such an implementation is built on the assumption that
-the value type is CopyConstructible and Assignable.</p>
-
-<p>It is common practice in the standard that algorithms explicitly
-specify any additional requirements that they impose on any of the
-types used by the algorithm. An example of an algorithm that creates
-temporary copies and correctly specifies the additional requirements
-is accumulate(), 26.4.1 [rand.req].</p>
-
-<p>Since the specifications of unique() and unique_copy() do not
-require CopyConstructible and Assignable of the InputIterator's value
-type the above mentioned implementations are not standard-compliant. I
-cannot judge whether this is a defect in the standard or a defect in
-the implementations.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 25.2.8 change:</p>
-
-<blockquote><p>
--4- Requires: The ranges [first, last) and [result, result+(last-first))
-shall not overlap.
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote>
- <p>-4- Requires: The ranges [first, last) and [result,
- result+(last-first)) shall not overlap. The expression *result =
- *first must be valid. If neither InputIterator nor OutputIterator
- meets the requirements of forward iterator then the value type of
- InputIterator must be copy constructible. Otherwise copy
- constructible is not required. </p>
-</blockquote>
-
-<p><i>[Redmond: the original proposed resolution didn't impose an
-explicit requirement that the iterator's value type must be copy
-constructible, on the grounds that an input iterator's value type must
-always be copy constructible. Not everyone in the LWG thought that
-this requirement was clear from table 72. It has been suggested that
-it might be possible to implement <tt>unique_copy</tt> without
-requiring assignability, although current implementations do impose
-that requirement. Howard provided new wording.]</i></p>
-
-
-<p><i>[
-Curaao: The LWG changed the PR editorially to specify
-"neither...nor...meet..." as clearer than
-"both...and...do not meet...". Change believed to be so
-minor as not to require re-review.
-]</i></p>
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="242"></a>242. Side effects of function objects</h3>
-<p><b>Section:</b> 25.2.4 [alg.transform], 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Angelika Langer <b>Date:</b> 2000-05-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.transform">issues</a> in [alg.transform].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The algorithms transform(), accumulate(), inner_product(),
-partial_sum(), and adjacent_difference() require that the function
-object supplied to them shall not have any side effects.</p>
-
-<p>The standard defines a side effect in 1.9 [intro.execution] as:</p>
-<blockquote><p>-7- Accessing an object designated by a volatile lvalue (basic.lval),
-modifying an object, calling a library I/O function, or calling a function
-that does any of those operations are all side effects, which are changes
-in the state of the execution environment.</p></blockquote>
-
-<p>As a consequence, the function call operator of a function object supplied
-to any of the algorithms listed above cannot modify data members, cannot
-invoke any function that has a side effect, and cannot even create and
-modify temporary objects.&nbsp; It is difficult to imagine a function object
-that is still useful under these severe limitations. For instance, any
-non-trivial transformator supplied to transform() might involve creation
-and modification of temporaries, which is prohibited according to the current
-wording of the standard.</p>
-
-<p>On the other hand, popular implementations of these algorithms exhibit
-uniform and predictable behavior when invoked with a side-effect-producing
-function objects. It looks like the strong requirement is not needed for
-efficient implementation of these algorithms.</p>
-
-<p>The requirement of&nbsp; side-effect-free function objects could be
-replaced by a more relaxed basic requirement (which would hold for all
-function objects supplied to any algorithm in the standard library):</p>
-<blockquote><p>A function objects supplied to an algorithm shall not invalidate
-any iterator or sequence that is used by the algorithm. Invalidation of
-the sequence includes destruction of the sorting order if the algorithm
-relies on the sorting order (see section 25.3 - Sorting and related operations
-[lib.alg.sorting]).</p></blockquote>
-
-<p>I can't judge whether it is intended that the function objects supplied
-to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
-shall not modify sequence elements through dereferenced iterators.</p>
-
-<p>It is debatable whether this issue is a defect or a change request.
-Since the consequences for user-supplied function objects are drastic and
-limit the usefulness of the algorithms significantly I would consider it
-a defect.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p><i>Things to notice about these changes:</i></p>
-
-<ol>
-<li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
- are intentional. we want to prevent side-effects from
- invalidating the end iterators.</i></li>
-
-<li> <i>That has the unintentional side-effect of prohibiting
- modification of the end element as a side-effect. This could
- conceivably be significant in some cases.</i></li>
-
-<li> <i>The wording also prevents side-effects from modifying elements
- of the output sequence. I can't imagine why anyone would want
- to do this, but it is arguably a restriction that implementors
- don't need to place on users.</i></li>
-
-<li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
- and simple, but would require more verbiage.</i></li>
-</ol>
-
-<p>Change 25.2.3/2 from:</p>
-
-<blockquote><p>
- -2- Requires: op and binary_op shall not have any side effects.
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
- -2- Requires: in the ranges [first1, last1], [first2, first2 +
- (last1 - first1)] and [result, result + (last1- first1)], op and
- binary_op shall neither modify elements nor invalidate iterators or
- subranges.
- [Footnote: The use of fully closed ranges is intentional --end footnote]
-</p></blockquote>
-
-
-<p>Change 25.2.3/2 from:</p>
-
-<blockquote><p>
- -2- Requires: op and binary_op shall not have any side effects.
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
- -2- Requires: op and binary_op shall not invalidate iterators or
- subranges, or modify elements in the ranges [first1, last1],
- [first2, first2 + (last1 - first1)], and [result, result + (last1
- - first1)].
- [Footnote: The use of fully closed ranges is intentional --end footnote]
-</p></blockquote>
-
-
-<p>Change 26.4.1/2 from:</p>
-
-<blockquote><p>
- -2- Requires: T must meet the requirements of CopyConstructible
- (lib.copyconstructible) and Assignable (lib.container.requirements)
- types. binary_op shall not cause side effects.
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
- -2- Requires: T must meet the requirements of CopyConstructible
- (lib.copyconstructible) and Assignable
- (lib.container.requirements) types. In the range [first, last],
- binary_op shall neither modify elements nor invalidate iterators
- or subranges.
- [Footnote: The use of a fully closed range is intentional --end footnote]
-</p></blockquote>
-
-<p>Change 26.4.2/2 from:</p>
-
-<blockquote><p>
- -2- Requires: T must meet the requirements of CopyConstructible
- (lib.copyconstructible) and Assignable (lib.container.requirements)
- types. binary_op1 and binary_op2 shall not cause side effects.
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
- -2- Requires: T must meet the requirements of CopyConstructible
- (lib.copyconstructible) and Assignable (lib.container.requirements)
- types. In the ranges [first, last] and [first2, first2 + (last -
- first)], binary_op1 and binary_op2 shall neither modify elements
- nor invalidate iterators or subranges.
- [Footnote: The use of fully closed ranges is intentional --end footnote]
-</p></blockquote>
-
-
-<p>Change 26.4.3/4 from:</p>
-
-<blockquote><p>
- -4- Requires: binary_op is expected not to have any side effects.
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
- -4- Requires: In the ranges [first, last] and [result, result +
- (last - first)], binary_op shall neither modify elements nor
- invalidate iterators or subranges.
- [Footnote: The use of fully closed ranges is intentional --end footnote]
-</p></blockquote>
-
-<p>Change 26.4.4/2 from:</p>
-
-<blockquote><p>
- -2- Requires: binary_op shall not have any side effects.
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
- -2- Requires: In the ranges [first, last] and [result, result +
- (last - first)], binary_op shall neither modify elements nor
- invalidate iterators or subranges.
- [Footnote: The use of fully closed ranges is intentional --end footnote]
-</p></blockquote>
-
-<p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
-
-
-<p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
-added footnotes pointing out that the use of closed ranges was
-intentional.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="243"></a>243. <tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-05-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
-are unclear with respect to the behavior and side-effects of the named
-functions in case of an error.</p>
-
-<p>27.6.1.3, p1 states that "... If the sentry object returns
-true, when converted to a value of type bool, the function endeavors
-to obtain the requested input..." It is not clear from this (or
-the rest of the paragraph) what precisely the behavior should be when
-the sentry ctor exits by throwing an exception or when the sentry
-object returns false. In particular, what is the number of characters
-extracted that gcount() returns supposed to be?</p>
-
-<p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
-"... In any case, it then stores a null character (using
-charT()) into the next successive location of the array." Is not
-clear whether this sentence applies if either of the conditions above
-holds (i.e., when sentry fails).</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add to 27.6.1.3, p1 after the sentence</p>
-
-<blockquote><p>
-"... If the sentry object returns true, when converted to a value of
-type bool, the function endeavors to obtain the requested input."
-</p></blockquote>
-
-<p>the following</p>
-
-
-<blockquote><p>
-"Otherwise, if the sentry constructor exits by throwing an exception or
-if the sentry object returns false, when converted to a value of type
-bool, the function returns without attempting to obtain any input. In
-either case the number of extracted characters is set to 0; unformatted
-input functions taking a character array of non-zero size as an argument
-shall also store a null character (using charT()) in the first location
-of the array."
-</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>Although the general philosophy of the input functions is that the
-argument should not be modified upon failure, <tt>getline</tt>
-historically added a terminating null unconditionally. Most
-implementations still do that. Earlier versions of the draft standard
-had language that made this an unambiguous requirement; those words
-were moved to a place where their context made them less clear. See
-Jerry Schwarz's message c++std-lib-7618.</p>
-
-
-
-
-<hr>
-<h3><a name="247"></a>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3>
-<p><b>Section:</b> 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 2000-06-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Paragraph 2 of 23.2.6.4 [vector.modifiers] describes the complexity
-of <tt>vector::insert</tt>:</p>
-
- <blockquote><p>
- Complexity: If first and last are forward iterators, bidirectional
- iterators, or random access iterators, the complexity is linear in
- the number of elements in the range [first, last) plus the distance
- to the end of the vector. If they are input iterators, the complexity
- is proportional to the number of elements in the range [first, last)
- times the distance to the end of the vector.
- </p></blockquote>
-
-<p>First, this fails to address the non-iterator forms of
-<tt>insert</tt>.</p>
-
-<p>Second, the complexity for input iterators misses an edge case --
-it requires that an arbitrary number of elements can be added at
-the end of a <tt>vector</tt> in constant time.</p>
-
-<p>I looked to see if <tt>deque</tt> had a similar problem, and was
-surprised to find that <tt>deque</tt> places no requirement on the
-complexity of inserting multiple elements (23.2.2.3 [deque.modifiers],
-paragraph 3):</p>
-
- <blockquote><p>
- Complexity: In the worst case, inserting a single element into a
- deque takes time linear in the minimum of the distance from the
- insertion point to the beginning of the deque and the distance
- from the insertion point to the end of the deque. Inserting a
- single element either at the beginning or end of a deque always
- takes constant time and causes a single call to the copy constructor
- of T.
- </p></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Change Paragraph 2 of 23.2.6.4 [vector.modifiers] to</p>
- <blockquote><p>
- Complexity: The complexity is linear in the number of elements
- inserted plus the distance to the end of the vector.
- </p></blockquote>
-
- <p><i>[For input iterators, one may achieve this complexity by first
- inserting at the end of the <tt>vector</tt>, and then using
- <tt>rotate</tt>.]</i></p>
-
-
-<p>Change 23.2.2.3 [deque.modifiers], paragraph 3, to:</p>
-
- <blockquote><p>
- Complexity: The complexity is linear in the number of elements
- inserted plus the shorter of the distances to the beginning and
- end of the deque. Inserting a single element at either the
- beginning or the end of a deque causes a single call to the copy
- constructor of T.
- </p></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>This is a real defect, and proposed resolution fixes it: some
- complexities aren't specified that should be. This proposed
- resolution does constrain deque implementations (it rules out the
- most naive possible implementations), but the LWG doesn't see a
- reason to permit that implementation.</p>
-
-
-
-
-
-<hr>
-<h3><a name="248"></a>248. time_get fails to set eofbit</h3>
-<p><b>Section:</b> 22.2.5 [category.time] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-06-22</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>There is no requirement that any of time_get member functions set
-ios::eofbit when they reach the end iterator while parsing their input.
-Since members of both the num_get and money_get facets are required to
-do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
-should follow the same requirement for consistency.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
-
-<blockquote><p>
-If the end iterator is reached during parsing by any of the get()
-member functions, the member sets ios_base::eofbit in err.
-</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>Two alternative resolutions were proposed. The LWG chose this one
-because it was more consistent with the way eof is described for other
-input facets.</p>
-
-
-
-
-<hr>
-<h3><a name="250"></a>250. splicing invalidates iterators</h3>
-<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Brian Parker <b>Date:</b> 2000-07-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 23.2.4.4 [list.ops] states that
-</p>
-<pre> void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
-</pre>
-<p>
-<i>invalidates</i> all iterators and references to list <tt>x</tt>.
-</p>
-
-<p>
-This is unnecessary and defeats an important feature of splice. In
-fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
-after <tt>splice</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Add a footnote to 23.2.4.4 [list.ops], paragraph 1:</p>
-<blockquote><p>
-[<i>Footnote:</i> As specified in [default.con.req], paragraphs
-4-5, the semantics described in this clause applies only to the case
-where allocators compare equal. --end footnote]
-</p></blockquote>
-
-<p>In 23.2.4.4 [list.ops], replace paragraph 4 with:</p>
-<blockquote><p>
-Effects: Inserts the contents of x before position and x becomes
-empty. Pointers and references to the moved elements of x now refer to
-those same elements but as members of *this. Iterators referring to the
-moved elements will continue to refer to their elements, but they now
-behave as iterators into *this, not into x.
-</p></blockquote>
-
-<p>In 23.2.4.4 [list.ops], replace paragraph 7 with:</p>
-<blockquote><p>
-Effects: Inserts an element pointed to by i from list x before
-position and removes the element from x. The result is unchanged if
-position == i or position == ++i. Pointers and references to *i continue
-to refer to this same element but as a member of *this. Iterators to *i
-(including i itself) continue to refer to the same element, but now
-behave as iterators into *this, not into x.
-</p></blockquote>
-
-<p>In 23.2.4.4 [list.ops], replace paragraph 12 with:</p>
-<blockquote><p>
-Requires: [first, last) is a valid range in x. The result is
-undefined if position is an iterator in the range [first, last).
-Pointers and references to the moved elements of x now refer to those
-same elements but as members of *this. Iterators referring to the moved
-elements will continue to refer to their elements, but they now behave as
-iterators into *this, not into x.
-</p></blockquote>
-
-<p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>The original proposed resolution said that iterators and references
-would remain "valid". The new proposed resolution clarifies what that
-means. Note that this only applies to the case of equal allocators.
-From [default.con.req] paragraph 4, the behavior of list when
-allocators compare nonequal is outside the scope of the standard.</p>
-
-
-
-
-<hr>
-<h3><a name="251"></a>251. basic_stringbuf missing allocator_type</h3>
-<p><b>Section:</b> 27.7.1 [stringbuf] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-07-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The synopsis for the template class <tt>basic_stringbuf</tt>
-doesn't list a typedef for the template parameter
-<tt>Allocator</tt>. This makes it impossible to determine the type of
-the allocator at compile time. It's also inconsistent with all other
-template classes in the library that do provide a typedef for the
-<tt>Allocator</tt> parameter.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
-basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
-basic_stringstream (27.7.4) the typedef:</p>
-<pre> typedef Allocator allocator_type;
-</pre>
-
-
-
-
-<hr>
-<h3><a name="252"></a>252. missing casts/C-style casts used in iostreams</h3>
-<p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-07-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
-const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
-The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
-D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
-the cast altogether.</p>
-
-<p>C-style casts have not been deprecated, so the first part of this
-issue is stylistic rather than a matter of correctness.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.7.2.2, p1 replace </p>
-<pre> -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
-
-<p>with</p>
-<pre> -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
-
-
-<p>In 27.7.3.2, p1 replace</p>
-<pre> -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
-
-<p>with</p>
-<pre> -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
-
-<p>In 27.7.6, p1, replace</p>
-<pre> -1- Returns: &amp;sb</pre>
-
-<p>with</p>
-<pre> -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
-
-<p>In D.7.2.2, p1 replace</p>
-<pre> -2- Returns: &amp;sb. </pre>
-
-<p>with</p>
-<pre> -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>
-
-
-
-
-<hr>
-<h3><a name="253"></a>253. valarray helper functions are almost entirely useless</h3>
-<p><b>Section:</b> 26.5.2.1 [valarray.cons], 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Robert Klarer <b>Date:</b> 2000-07-31</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>This discussion is adapted from message c++std-lib-7056 posted
-November 11, 1999. I don't think that anyone can reasonably claim
-that the problem described below is NAD.</p>
-
-<p>These valarray constructors can never be called:</p>
-
-<pre> template &lt;class T&gt;
- valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
- template &lt;class T&gt;
- valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
- template &lt;class T&gt;
- valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
- template &lt;class T&gt;
- valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
-</pre>
-
-<p>Similarly, these valarray assignment operators cannot be
-called:</p>
-
-<pre> template &lt;class T&gt;
- valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
- template &lt;class T&gt;
- valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
- template &lt;class T&gt;
- valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
- template &lt;class T&gt;
- valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
-</pre>
-
-<p>Please consider the following example:</p>
-
-<pre> #include &lt;valarray&gt;
- using namespace std;
-
- int main()
- {
- valarray&lt;double&gt; va1(12);
- valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
- }
-</pre>
-
-
-<p>Since the valarray va1 is non-const, the result of the sub-expression
-va1[slice(1,4,3)] at line 1 is an rvalue of type const
-std::slice_array&lt;double&gt;. This slice_array rvalue is then used to
-construct va2. The constructor that is used to construct va2 is
-declared like this:</p>
-
-<pre> template &lt;class T&gt;
- valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
-</pre>
-
-<p>Notice the constructor's const reference parameter. When the
-constructor is called, a slice_array must be bound to this reference.
-The rules for binding an rvalue to a const reference are in 8.5.3,
-paragraph 5 (see also 13.3.3.1.4). Specifically, paragraph 5
-indicates that a second slice_array rvalue is constructed (in this
-case copy-constructed) from the first one; it is this second rvalue
-that is bound to the reference parameter. Paragraph 5 also requires
-that the constructor that is used for this purpose be callable,
-regardless of whether the second rvalue is elided. The
-copy-constructor in this case is not callable, however, because it is
-private. Therefore, the compiler should report an error.</p>
-
-<p>Since slice_arrays are always rvalues, the valarray constructor that has a
-parameter of type const slice_array&lt;T&gt; &amp; can never be called. The
-same reasoning applies to the three other constructors and the four
-assignment operators that are listed at the beginning of this post.
-Furthermore, since these functions cannot be called, the valarray helper
-classes are almost entirely useless.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>slice_array:</p>
-<ul>
-<li> Make the copy constructor and copy-assignment operator declarations
- public in the slice_array class template definition in 26.5.5 [template.slice.array] </li>
-<li> remove paragraph 3 of 26.5.5 [template.slice.array]</li>
-<li> remove the copy constructor declaration from [cons.slice.arr]</li>
-<li> change paragraph 1 of [cons.slice.arr] to read "This constructor is declared
- to be private. This constructor need not be defined."</li>
-<li> remove the first sentence of paragraph 1 of 26.5.5.1 [slice.arr.assign]</li>
-<li> Change the first three words of the second sentence of paragraph 1 of
- 26.5.5.1 [slice.arr.assign] to "These assignment operators have"</li>
-</ul>
-
-<p>gslice_array:</p>
-<ul>
-<li> Make the copy constructor and copy-assignment operator declarations
- public in the gslice_array class template definition in 26.5.7 [template.gslice.array] </li>
-<li> remove the note in paragraph 3 of 26.5.7 [template.gslice.array]</li>
-<li> remove the copy constructor declaration from [gslice.array.cons]</li>
-<li> change paragraph 1 of [gslice.array.cons] to read "This constructor is declared
- to be private. This constructor need not be defined."</li>
-<li> remove the first sentence of paragraph 1 of 26.5.7.1 [gslice.array.assign]</li>
-<li> Change the first three words of the second sentence of paragraph 1 of
- 26.5.7.1 [gslice.array.assign] to "These assignment operators have"</li>
-</ul>
-
-<p>mask_array:</p>
-<ul>
-<li> Make the copy constructor and copy-assignment operator declarations
- public in the mask_array class template definition in 26.5.8 [template.mask.array] </li>
-<li> remove the note in paragraph 2 of 26.5.8 [template.mask.array]</li>
-<li> remove the copy constructor declaration from [mask.array.cons]</li>
-<li> change paragraph 1 of [mask.array.cons] to read "This constructor is declared
- to be private. This constructor need not be defined."</li>
-<li> remove the first sentence of paragraph 1 of 26.5.8.1 [mask.array.assign]</li>
-<li> Change the first three words of the second sentence of paragraph 1 of
- 26.5.8.1 [mask.array.assign] to "These assignment operators have"</li>
-</ul>
-
-<p>indirect_array:</p>
-<ul>
-<li>Make the copy constructor and copy-assignment operator declarations
- public in the indirect_array class definition in 26.5.9 [template.indirect.array]</li>
-<li> remove the note in paragraph 2 of 26.5.9 [template.indirect.array]</li>
-<li> remove the copy constructor declaration from [indirect.array.cons]</li>
-<li> change the descriptive text in [indirect.array.cons] to read "This constructor is
- declared to be private. This constructor need not be defined."</li>
-<li> remove the first sentence of paragraph 1 of 26.5.9.1 [indirect.array.assign]</li>
-<li> Change the first three words of the second sentence of paragraph 1 of
- 26.5.9.1 [indirect.array.assign] to "These assignment operators have"</li>
-</ul>
-<p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
-copy constructor and copy assignment operators public, instead of
-removing them.]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>Keeping the valarray constructors private is untenable. Merely
-making valarray a friend of the helper classes isn't good enough,
-because access to the copy constructor is checked in the user's
-environment.</p>
-
-<p>Making the assignment operator public is not strictly necessary to
-solve this problem. A majority of the LWG <i>(straw poll: 13-4)</i>
-believed we should make the assignment operators public, in addition
-to the copy constructors, for reasons of symmetry and user
-expectation.</p>
-
-
-
-
-
-<hr>
-<h3><a name="254"></a>254. Exception types in clause 19 are constructed from <tt>std::string</tt></h3>
-<p><b>Section:</b> 19.1 [std.exceptions], 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2000-08-01</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Many of the standard exception types which implementations are
-required to throw are constructed with a const std::string&amp;
-parameter. For example:
-</p>
-
-<pre> 19.1.5 Class out_of_range [lib.out.of.range]
- namespace std {
- class out_of_range : public logic_error {
- public:
- explicit out_of_range(const string&amp; what_arg);
- };
- }
-
- 1 The class out_of_range defines the type of objects thrown as excep-
- tions to report an argument value not in its expected range.
-
- out_of_range(const string&amp; what_arg);
-
- Effects:
- Constructs an object of class out_of_range.
- Postcondition:
- strcmp(what(), what_arg.c_str()) == 0.
-</pre>
-
-<p>
-There are at least two problems with this:
-</p>
-<ol>
-<li>A program which is low on memory may end up throwing
-std::bad_alloc instead of out_of_range because memory runs out while
-constructing the exception object.</li>
-<li>An obvious implementation which stores a std::string data member
-may end up invoking terminate() during exception unwinding because the
-exception object allocates memory (or rather fails to) as it is being
-copied.</li>
-</ol>
-
-<p>
-There may be no cure for (1) other than changing the interface to
-out_of_range, though one could reasonably argue that (1) is not a
-defect. Personally I don't care that much if out-of-memory is reported
-when I only have 20 bytes left, in the case when out_of_range would
-have been reported. People who use exception-specifications might care
-a lot, though.
-</p>
-
-<p>
-There is a cure for (2), but it isn't completely obvious. I think a
-note for implementors should be made in the standard. Avoiding
-possible termination in this case shouldn't be left up to chance. The
-cure is to use a reference-counted "string" implementation
-in the exception object. I am not necessarily referring to a
-std::string here; any simple reference-counting scheme for a NTBS
-would do.
-</p>
-
-<p><b>Further discussion, in email:</b></p>
-
-<p>
-...I'm not so concerned about (1). After all, a library implementation
-can add const char* constructors as an extension, and users don't
-<i>need</i> to avail themselves of the standard exceptions, though this is
-a lame position to be forced into. FWIW, std::exception and
-std::bad_alloc don't require a temporary basic_string.
-</p>
-
-<p>
-...I don't think the fixed-size buffer is a solution to the problem,
-strictly speaking, because you can't satisfy the postcondition
-<br>
- <tt>&nbsp;&nbsp;strcmp(what(), what_arg.c_str()) == 0</tt>
-<br>
-For all values of what_arg (i.e. very long values). That means that
-the only truly conforming solution requires a dynamic allocation.
-</p>
-
-<p><b>Further discussion, from Redmond:</b></p>
-
-<p>The most important progress we made at the Redmond meeting was
-realizing that there are two separable issues here: the const
-string&amp; constructor, and the copy constructor. If a user writes
-something like <tt>throw std::out_of_range("foo")</tt>, the const
-string&amp; constructor is invoked before anything gets thrown. The
-copy constructor is potentially invoked during stack unwinding.</p>
-
-<p>The copy constructor is a more serious problem, becuase failure
-during stack unwinding invokes <tt>terminate</tt>. The copy
-constructor must be nothrow. <i>Curaao: Howard thinks this
-requirement may already be present.</i></p>
-
-<p>The fundamental problem is that it's difficult to get the nothrow
-requirement to work well with the requirement that the exception
-objects store a string of unbounded size, particularly if you also try
-to make the const string&amp; constructor nothrow. Options discussed
-include:</p>
-
-<ul>
-<li>Limit the size of a string that exception objects are required to
-throw: change the postconditions of 19.1.2 [domain.error] paragraph 3
-and 19.1.6 [runtime.error] paragraph 3 to something like this:
-"strncmp(what(), what_arg._str(), N) == 0, where N is an
-implementation defined constant no smaller than 256".</li>
-<li>Allow the const string&amp; constructor to throw, but not the
-copy constructor. It's the implementor's responsibility to get it
-right. (An implementor might use a simple refcount class.)</li>
-<li>Compromise between the two: an implementation is not allowed to
-throw if the string's length is less than some N, but, if it doesn't
-throw, the string must compare equal to the argument.</li>
-<li>Add a new constructor that takes a const char*</li>
-</ul>
-
-<p>(Not all of these options are mutually exclusive.)</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 19.1.1 [logic.error]
-</p>
-
-<blockquote>
-<pre>namespace std {
- class logic_error : public exception {
- public:
- explicit logic_error(const string&amp; <i>what_arg</i>);
- <ins>explicit logic_error(const char* <i>what_arg</i>);</ins>
- };
-}
-</pre>
-<p>...</p>
-<p>
-<ins><tt>logic_error(const char* <i>what_arg</i>);</tt></ins>
-</p>
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Constructs an object of class <tt>logic_error</tt>.
-</ins></p>
-<p><ins>
--5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-<p>
-Change 19.1.2 [domain.error]
-</p>
-
-<blockquote>
-<pre>namespace std {
- class domain_error : public logic_error {
- public:
- explicit domain_error(const string&amp; <i>what_arg</i>);
- <ins>explicit domain_error(const char* <i>what_arg</i>);</ins>
- };
-}
-</pre>
-<p>...</p>
-<p>
-<ins><tt>domain_error(const char* <i>what_arg</i>);</tt></ins>
-</p>
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Constructs an object of class <tt>domain_error</tt>.
-</ins></p>
-<p><ins>
--5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
-</ins></p>
-
-</blockquote>
-</blockquote>
-
-<p>
-Change 19.1.3 [invalid.argument]
-</p>
-
-<blockquote>
-<pre>namespace std {
- class invalid_argument : public logic_error {
- public:
- explicit invalid_argument(const string&amp; <i>what_arg</i>);
- <ins>explicit invalid_argument(const char* <i>what_arg</i>);</ins>
- };
-}
-</pre>
-<p>...</p>
-<p>
-<ins><tt>invalid_argument(const char* <i>what_arg</i>);</tt></ins>
-</p>
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Constructs an object of class <tt>invalid_argument</tt>.
-</ins></p>
-<p><ins>
--5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-<p>
-Change 19.1.4 [length.error]
-</p>
-
-<blockquote>
-<pre>namespace std {
- class length_error : public logic_error {
- public:
- explicit length_error(const string&amp; <i>what_arg</i>);
- <ins>explicit length_error(const char* <i>what_arg</i>);</ins>
- };
-}
-</pre>
-<p>...</p>
-<p>
-<ins><tt>length_error(const char* <i>what_arg</i>);</tt></ins>
-</p>
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Constructs an object of class <tt>length_error</tt>.
-</ins></p>
-<p><ins>
--5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-<p>
-Change 19.1.5 [out.of.range]
-</p>
-
-<blockquote>
-<pre>namespace std {
- class out_of_range : public logic_error {
- public:
- explicit out_of_range(const string&amp; <i>what_arg</i>);
- <ins>explicit out_of_range(const char* <i>what_arg</i>);</ins>
- };
-}
-</pre>
-<p>...</p>
-<p>
-<ins><tt>out_of_range(const char* <i>what_arg</i>);</tt></ins>
-</p>
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Constructs an object of class <tt>out_of_range</tt>.
-</ins></p>
-<p><ins>
--5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-<p>
-Change 19.1.6 [runtime.error]
-</p>
-
-<blockquote>
-<pre>namespace std {
- class runtime_error : public exception {
- public:
- explicit runtime_error(const string&amp; <i>what_arg</i>);
- <ins>explicit runtime_error(const char* <i>what_arg</i>);</ins>
- };
-}
-</pre>
-<p>...</p>
-<p>
-<ins><tt>runtime_error(const char* <i>what_arg</i>);</tt></ins>
-</p>
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Constructs an object of class <tt>runtime_error</tt>.
-</ins></p>
-<p><ins>
--5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-<p>
-Change 19.1.7 [range.error]
-</p>
-
-<blockquote>
-<pre>namespace std {
- class range_error : public runtime_error {
- public:
- explicit range_error(const string&amp; <i>what_arg</i>);
- <ins>explicit range_error(const char* <i>what_arg</i>);</ins>
- };
-}
-</pre>
-<p>...</p>
-<p>
-<ins><tt>range_error(const char* <i>what_arg</i>);</tt></ins>
-</p>
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Constructs an object of class <tt>range_error</tt>.
-</ins></p>
-<p><ins>
--5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-<p>
-Change 19.1.8 [overflow.error]
-</p>
-
-<blockquote>
-<pre>namespace std {
- class overflow_error : public runtime_error {
- public:
- explicit overflow_error(const string&amp; <i>what_arg</i>);
- <ins>explicit overflow_error(const char* <i>what_arg</i>);</ins>
- };
-}
-</pre>
-<p>...</p>
-<p>
-<ins><tt>overflow_error(const char* <i>what_arg</i>);</tt></ins>
-</p>
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Constructs an object of class <tt>overflow_error</tt>.
-</ins></p>
-<p><ins>
--5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-<p>
-Change 19.1.9 [underflow.error]
-</p>
-
-<blockquote>
-<pre>namespace std {
- class underflow_error : public runtime_error {
- public:
- explicit underflow_error(const string&amp; <i>what_arg</i>);
- <ins>explicit underflow_error(const char* <i>what_arg</i>);</ins>
- };
-}
-</pre>
-<p>...</p>
-<p>
-<ins><tt>underflow_error(const char* <i>what_arg</i>);</tt></ins>
-</p>
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Constructs an object of class <tt>underflow_error</tt>.
-</ins></p>
-<p><ins>
--5- <i>Postcondition:</i> <tt>strcmp(what(), <i>what_arg</i>) == 0</tt>.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-<p>
-Change 27.4.2.1.1 [ios::failure]
-</p>
-
-<blockquote>
-<pre>namespace std {
- class ios_base::failure : public exception {
- public:
- explicit failure(const string&amp; <i>msg</i>);
- <ins>explicit failure(const char* <i>msg</i>);</ins>
- virtual const char* what() const throw();
-};
-}
-</pre>
-<p>...</p>
-<p>
-<ins><tt>failure(const char* <i>msg</i>);</tt></ins>
-</p>
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Constructs an object of class <tt>failure</tt>.
-</ins></p>
-<p><ins>
--5- <i>Postcondition:</i> <tt>strcmp(what(), <i>msg</i>) == 0</tt>.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-
-<p>Throwing a bad_alloc while trying to construct a message for another
-exception-derived class is not necessarily a bad thing. And the
-bad_alloc constructor already has a no throw spec on it (18.4.2.1).</p>
-
-<p><b>Future:</b></p>
-
-<p>All involved would like to see const char* constructors added, but
-this should probably be done for C++0X as opposed to a DR.</p>
-
-<p>I believe the no throw specs currently decorating these functions
-could be improved by some kind of static no throw spec checking
-mechanism (in a future C++ language). As they stand, the copy
-constructors might fail via a call to unexpected. I think what is
-intended here is that the copy constructors can't fail.</p>
-
-<p><i>[Pre-Sydney: reopened at the request of Howard Hinnant.
- Post-Redmond: James Kanze noticed that the copy constructors of
- exception-derived classes do not have nothrow clauses. Those
- classes have no copy constructors declared, meaning the
- compiler-generated implicit copy constructors are used, and those
- compiler-generated constructors might in principle throw anything.]</i></p>
-
-
-<p><i>[
-Batavia: Merged copy constructor and assignment operator spec into <tt>exception</tt>
-and added <tt>ios::failure</tt> into the proposed resolution.
-]</i></p>
-
-
-<p><i>[
-Oxford: The proposed resolution simply addresses the issue of constructing
-the exception objects with <tt>const char*</tt> and string literals without
-the need to explicit include or construct a <tt>std::string</tt>.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="256"></a>256. typo in 27.4.4.2, p17: copy_event does not exist</h3>
-<p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-21</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-27.4.4.2, p17 says
-</p>
-
-<blockquote><p>
--17- Before copying any parts of rhs, calls each registered callback
-pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
-exceptions() have been replaced, calls each callback pair that was
-copied from rhs as (*fn)(copy_event,*this,index).
-</p></blockquote>
-
-<p>
-The name copy_event isn't defined anywhere. The intended name was
-copyfmt_event.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace copy_event with copyfmt_event in the named paragraph.</p>
-
-
-
-
-<hr>
-<h3><a name="258"></a>258. Missing allocator requirement</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-08-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-From lib-7752:
-</p>
-
-<p>
-I've been assuming (and probably everyone else has been assuming) that
-allocator instances have a particular property, and I don't think that
-property can be deduced from anything in Table 32.
-</p>
-
-<p>
-I think we have to assume that allocator type conversion is a
-homomorphism. That is, if x1 and x2 are of type X, where
-X::value_type is T, and if type Y is X::template
-rebind&lt;U&gt;::other, then Y(x1) == Y(x2) if and only if x1 == x2.
-</p>
-
-<p>
-Further discussion: Howard Hinnant writes, in lib-7757:
-</p>
-
-<p>
-I think I can prove that this is not provable by Table 32. And I agree
-it needs to be true except for the "and only if". If x1 != x2, I see no
-reason why it can't be true that Y(x1) == Y(x2). Admittedly I can't
-think of a practical instance where this would happen, or be valuable.
-But I also don't see a need to add that extra restriction. I think we
-only need:
-</p>
-
-<blockquote><p>
- if (x1 == x2) then Y(x1) == Y(x2)
-</p></blockquote>
-
-<p>
-If we decide that == on allocators is transitive, then I think I can
-prove the above. But I don't think == is necessarily transitive on
-allocators. That is:
-</p>
-
-<p>
-Given x1 == x2 and x2 == x3, this does not mean x1 == x3.
-</p>
-
-<p>Example:</p>
-
-<blockquote>
-<p>
-x1 can deallocate pointers from: x1, x2, x3 <br>
-x2 can deallocate pointers from: x1, x2, x4 <br>
-x3 can deallocate pointers from: x1, x3 <br>
-x4 can deallocate pointers from: x2, x4
-</p>
-
-<p>
-x1 == x2, and x2 == x4, but x1 != x4
-</p>
-</blockquote>
-<p><i>[Toronto: LWG members offered multiple opinions. One
-opinion is that it should not be required that <tt>x1 == x2</tt>
-implies <tt>Y(x1) == Y(x2)</tt>, and that it should not even be
-required that <tt>X(x1) == x1</tt>. Another opinion is that
-the second line from the bottom in table 32 already implies the
-desired property. This issue should be considered in light of
-other issues related to allocator instances.]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Accept proposed wording from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 3.
-</p>
-
-
-<p><i>[Lillehammer: Same conclusion as before: this should be
- considered as part of an allocator redesign, not solved on its own.]</i></p>
-
-
-<p><i>[
-Batavia: An allocator redesign is not forthcoming and thus we fixed this one issue.
-]</i></p>
-
-
-<p><i>[
-Toronto: Reopened at the request of the project editor (Pete) because the proposed
-wording did not fit within the indicated table. The intent of the resolution remains
-unchanged. Pablo to work with Pete on improved wording.
-]</i></p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
-was subsequently split out into a separate paper N2436 for the purposes of voting.
-The resolution in N2436 addresses this issue. The LWG voted to accelerate this
-issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="259"></a>259. <tt>basic_string::operator[]</tt> and const correctness</h3>
-<p><b>Section:</b> 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Chris Newton <b>Date:</b> 2000-08-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.capacity">issues</a> in [string.capacity].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
-</p>
-
-<p>
-The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
-seems to violate const correctness.
-</p>
-
-<p>
-The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
-returns <tt>data()[pos]</tt>." The types don't work. The
-return value of <tt>data()</tt> is <tt>const charT*</tt>, but
-<tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In section 21.3.4, paragraph 1, change
-"<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
-<i>pos</i>)</tt>".
-</p>
-
-
-
-
-<hr>
-<h3><a name="260"></a>260. Inconsistent return type of <tt>istream_iterator::operator++(int)</tt></h3>
-<p><b>Section:</b> 24.5.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.ops">issues</a> in [istream.iterator.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
-it as returning the iterator by value. 24.5.1.2, p5 shows the same
-operator as returning the iterator by reference. That's incorrect
-given the Effects clause below (since a temporary is returned). The
-`&amp;' is probably just a typo.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the declaration in 24.5.1.2, p5 from</p>
- <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
- </pre>
-<p>to</p>
- <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
- </pre>
-<p>(that is, remove the `&amp;').</p>
-
-
-
-
-<hr>
-<h3><a name="261"></a>261. Missing description of <tt>istream_iterator::operator!=</tt></h3>
-<p><b>Section:</b> 24.5.1.2 [istream.iterator.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-08-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.iterator.ops">issues</a> in [istream.iterator.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-24.5.1, p3 lists the synopsis for
-</p>
-
-<pre> template &lt;class T, class charT, class traits, class Distance&gt;
- bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
- const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
-</pre>
-
-<p>
-but there is no description of what the operator does (i.e., no Effects
-or Returns clause) in 24.5.1.2.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add paragraph 7 to the end of section 24.5.1.2 with the following text:
-</p>
-
-<pre> template &lt;class T, class charT, class traits, class Distance&gt;
- bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
- const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
-</pre>
-
-<p>-7- Returns: !(x == y).</p>
-
-
-
-
-<hr>
-<h3><a name="262"></a>262. Bitmask operator ~ specified incorrectly</h3>
-<p><b>Section:</b> 17.3.2.1.2 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2000-09-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The ~ operation should be applied after the cast to int_type.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
-</p>
-
-<pre> bitmask operator~ ( bitmask X )
- { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
-</pre>
-
-<p>
-to:
-</p>
-
-<pre> bitmask operator~ ( bitmask X )
- { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
-</pre>
-
-
-
-
-<hr>
-<h3><a name="263"></a>263. Severe restriction on <tt>basic_string</tt> reference counting</h3>
-<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Kevlin Henney <b>Date:</b> 2000-09-04</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The note in paragraph 6 suggests that the invalidation rules for
-references, pointers, and iterators in paragraph 5 permit a reference-
-counted implementation (actually, according to paragraph 6, they permit
-a "reference counted implementation", but this is a minor editorial fix).
-</p>
-
-<p>
-However, the last sub-bullet is so worded as to make a reference-counted
-implementation unviable. In the following example none of the
-conditions for iterator invalidation are satisfied:
-</p>
-
-<pre> // first example: "*******************" should be printed twice
- string original = "some arbitrary text", copy = original;
- const string &amp; alias = original;
-
- string::const_iterator i = alias.begin(), e = alias.end();
- for(string::iterator j = original.begin(); j != original.end(); ++j)
- *j = '*';
- while(i != e)
- cout &lt;&lt; *i++;
- cout &lt;&lt; endl;
- cout &lt;&lt; original &lt;&lt; endl;
-</pre>
-
-<p>
-Similarly, in the following example:
-</p>
-
-<pre> // second example: "some arbitrary text" should be printed out
- string original = "some arbitrary text", copy = original;
- const string &amp; alias = original;
-
- string::const_iterator i = alias.begin();
- original.begin();
- while(i != alias.end())
- cout &lt;&lt; *i++;
-</pre>
-
-<p>
-I have tested this on three string implementations, two of which were
-reference counted. The reference-counted implementations gave
-"surprising behavior" because they invalidated iterators on
-the first call to non-const begin since construction. The current
-wording does not permit such invalidation because it does not take
-into account the first call since construction, only the first call
-since various member and non-member function calls.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the following sentence in 21.3 paragraph 5 from
-</p>
-
-<blockquote><p>
- Subsequent to any of the above uses except the forms of insert() and
- erase() which return iterators, the first call to non-const member
- functions operator[](), at(), begin(), rbegin(), end(), or rend().
-</p></blockquote>
-
-<p>to</p>
-
-<blockquote><p>
- Following construction or any of the above uses, except the forms of
- insert() and erase() that return iterators, the first call to non-
- const member functions operator[](), at(), begin(), rbegin(), end(),
- or rend().
-</p></blockquote>
-
-
-
-
-<hr>
-<h3><a name="264"></a>264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> John Potter <b>Date:</b> 2000-09-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></p>
-<p><b>Discussion:</b></p>
-<p>
-Table 69 requires linear time if [i, j) is sorted. Sorted is necessary but not sufficient.
-Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
-integers in the same range.
-</p>
-
-<p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In Table 69, in section 23.1.2, change the complexity clause for
-insertion of a range from "N log(size() + N) (N is the distance
-from i to j) in general; linear if [i, j) is sorted according to
-value_comp()" to "N log(size() + N), where N is the distance
-from i to j".
-</p>
-
-<p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
-parens in the revised wording.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Testing for valid insertions could be less efficient than simply
-inserting the elements when the range is not both sorted and between
-two adjacent existing elements; this could be a QOI issue.
-</p>
-
-<p>
-The LWG considered two other options: (a) specifying that the
-complexity was linear if [i, j) is sorted according to value_comp()
-and between two adjacent existing elements; or (b) changing to
-Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
-number of elements which do not insert immediately after the previous
-element from [i, j) including the first). The LWG felt that, since
-we can't guarantee linear time complexity whenever the range to be
-inserted is sorted, it's more trouble than it's worth to say that it's
-linear in some special cases.
-</p>
-
-
-
-
-<hr>
-<h3><a name="265"></a>265. std::pair::pair() effects overly restrictive</h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-09-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I don't see any requirements on the types of the elements of the
-std::pair container in 20.2.2. From the descriptions of the member
-functions it appears that they must at least satisfy the requirements of
-20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
-the case of the [in]equality operators also the requirements of 20.1.1
-[lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
-</p>
-
-<p>
-I believe that the the CopyConstructible requirement is unnecessary in
-the case of 20.2.2, p2.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the Effects clause in 20.2.2, p2 from</p>
-
-<blockquote><p>
--2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
-first(T1()), second(T2()) {} </tt>
-</p></blockquote>
-
-<p>to</p>
-
-<blockquote><p>
--2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
-first(), second() {} </tt>
-</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>The existing specification of pair's constructor appears to be a
-historical artifact: there was concern that pair's members be properly
-zero-initialized when they are built-in types. At one time there was
-uncertainty about whether they would be zero-initialized if the
-default constructor was written the obvious way. This has been
-clarified by core issue 178, and there is no longer any doubt that
-the straightforward implementation is correct.</p>
-
-
-
-
-<hr>
-<h3><a name="266"></a>266. bad_exception::~bad_exception() missing Effects clause</h3>
-<p><b>Section:</b> 18.7.2.1 [bad.exception] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-09-24</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The synopsis for std::bad_exception lists the function ~bad_exception()
-but there is no description of what the function does (the Effects
-clause is missing).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove the destructor from the class synopses of
-<tt>bad_alloc</tt> (18.5.2.1 [bad.alloc]),
-<tt>bad_cast</tt> (18.6.2 [bad.cast]),
-<tt>bad_typeid</tt> (18.6.3 [bad.typeid]),
-and <tt>bad_exception</tt> (18.7.2.1 [bad.exception]).
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-This is a general problem with the exception classes in clause 18.
-The proposed resolution is to remove the destructors from the class
-synopses, rather than to document the destructors' behavior, because
-removing them is more consistent with how exception classes are
-described in clause 19.
-</p>
-
-
-
-
-<hr>
-<h3><a name="268"></a>268. Typo in locale synopsis</h3>
-<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-10-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The synopsis of the class std::locale in 22.1.1 contains two typos:
-the semicolons after the declarations of the default ctor
-locale::locale() and the copy ctor locale::locale(const locale&amp;)
-are missing.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add the missing semicolons, i.e., change</p>
-
-<pre> // construct/copy/destroy:
- locale() throw()
- locale(const locale&amp; other) throw()
-</pre>
-
-<p>in the synopsis in 22.1.1 to</p>
-
-<pre> // construct/copy/destroy:
- locale() throw();
- locale(const locale&amp; other) throw();
-</pre>
-
-
-
-
-<hr>
-<h3><a name="270"></a>270. Binary search requirements overly strict</h3>
-<p><b>Section:</b> 25.3.3 [alg.binary.search] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-10-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.binary.search">issues</a> in [alg.binary.search].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#472">472</a></p>
-<p><b>Discussion:</b></p>
-<p>
-Each of the four binary search algorithms (lower_bound, upper_bound,
-equal_range, binary_search) has a form that allows the user to pass a
-comparison function object. According to 25.3, paragraph 2, that
-comparison function object has to be a strict weak ordering.
-</p>
-
-<p>
-This requirement is slightly too strict. Suppose we are searching
-through a sequence containing objects of type X, where X is some
-large record with an integer key. We might reasonably want to look
-up a record by key, in which case we would want to write something
-like this:
-</p>
-<pre> struct key_comp {
- bool operator()(const X&amp; x, int n) const {
- return x.key() &lt; n;
- }
- }
-
- std::lower_bound(first, last, 47, key_comp());
-</pre>
-
-<p>
-key_comp is not a strict weak ordering, but there is no reason to
-prohibit its use in lower_bound.
-</p>
-
-<p>
-There's no difficulty in implementing lower_bound so that it allows
-the use of something like key_comp. (It will probably work unless an
-implementor takes special pains to forbid it.) What's difficult is
-formulating language in the standard to specify what kind of
-comparison function is acceptable. We need a notion that's slightly
-more general than that of a strict weak ordering, one that can encompass
-a comparison function that involves different types. Expressing that
-notion may be complicated.
-</p>
-
-<p><i>Additional questions raised at the Toronto meeting:</i></p>
-<ul>
-<li> Do we really want to specify what ordering the implementor must
- use when calling the function object? The standard gives
- specific expressions when describing these algorithms, but it also
- says that other expressions (with different argument order) are
- equivalent.</li>
-<li> If we are specifying ordering, note that the standard uses both
- orderings when describing <tt>equal_range</tt>.</li>
-<li> Are we talking about requiring these algorithms to work properly
- when passed a binary function object whose two argument types
- are not the same, or are we talking about requirements when
- they are passed a binary function object with several overloaded
- versions of <tt>operator()</tt>?</li>
-<li> The definition of a strict weak ordering does not appear to give
- any guidance on issues of overloading; it only discusses expressions,
- and all of the values in these expressions are of the same type.
- Some clarification would seem to be in order.</li>
-</ul>
-
-<p><i>Additional discussion from Copenhagen:</i></p>
-<ul>
-<li>It was generally agreed that there is a real defect here: if
-the predicate is merely required to be a Strict Weak Ordering, then
-it's possible to pass in a function object with an overloaded
-operator(), where the version that's actually called does something
-completely inappropriate. (Such as returning a random value.)</li>
-
-<li>An alternative formulation was presented in a paper distributed by
-David Abrahams at the meeting, "Binary Search with Heterogeneous
-Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
-predicate as a Strict Weak Ordering acting on a sorted sequence, view
-the predicate/value pair as something that partitions a sequence.
-This is almost equivalent to saying that we should view binary search
-as if we are given a unary predicate and a sequence, such that f(*p)
-is true for all p below a specific point and false for all p above it.
-The proposed resolution is based on that alternative formulation.</li>
-</ul>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
-
-<blockquote><p>
- 3 For all algorithms that take Compare, there is a version that uses
- operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
- *j != false. For the algorithms to work correctly, comp has to
- induce a strict weak ordering on the values.
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
- 3 For all algorithms that take Compare, there is a version that uses
- operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
- &lt; *j != false. For algorithms other than those described in
- lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
- a strict weak ordering on the values.
-</p></blockquote>
-
-<p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
-
-<blockquote><p>
- -6- A sequence [start, finish) is partitioned with respect to an
- expression f(e) if there exists an integer n such that
- for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
- and only if i &lt; n.
-</p></blockquote>
-
-<p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
-
-<blockquote><p>
- -1- All of the algorithms in this section are versions of binary
- search and assume that the sequence being searched is in order
- according to the implied or explicit comparison function. They work
- on non-random access iterators minimizing the number of
- comparisons, which will be logarithmic for all types of
- iterators. They are especially appropriate for random access
- iterators, because these algorithms do a logarithmic number of
- steps through the data structure. For non-random access iterators
- they execute a linear number of steps.
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
- -1- All of the algorithms in this section are versions of binary
- search and assume that the sequence being searched is partitioned
- with respect to an expression formed by binding the search key to
- an argument of the implied or explicit comparison function. They
- work on non-random access iterators minimizing the number of
- comparisons, which will be logarithmic for all types of
- iterators. They are especially appropriate for random access
- iterators, because these algorithms do a logarithmic number of
- steps through the data structure. For non-random access iterators
- they execute a linear number of steps.
-</p></blockquote>
-
-<p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
-
-<blockquote><p>
- -1- Requires: Type T is LessThanComparable
- (lib.lessthancomparable).
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
- -1- Requires: The elements e of [first, last) are partitioned with
- respect to the expression e &lt; value or comp(e, value)
-</p></blockquote>
-
-
-<p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
-
-<blockquote><p>
- -2- Effects: Finds the first position into which value can be
- inserted without violating the ordering.
-</p></blockquote>
-
-<p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
-
-<blockquote><p>
- -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
- -1- Requires: The elements e of [first, last) are partitioned with
- respect to the expression !(value &lt; e) or !comp(value, e)
-</p></blockquote>
-
-<p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
-
-<blockquote><p>
- -2- Effects: Finds the furthermost position into which value can be
- inserted without violating the ordering.
-</p></blockquote>
-
-<p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
-
-<blockquote><p>
- -1- Requires: Type T is LessThanComparable
- (lib.lessthancomparable).
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
- -1- Requires: The elements e of [first, last) are partitioned with
- respect to the expressions e &lt; value and !(value &lt; e) or
- comp(e, value) and !comp(value, e). Also, for all elements e of
- [first, last), e &lt; value implies !(value &lt; e) or comp(e,
- value) implies !comp(value, e)
-</p></blockquote>
-
-<p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
-
-<blockquote><p>
- -2- Effects: Finds the largest subrange [i, j) such that the value
- can be inserted at any iterator k in it without violating the
- ordering. k satisfies the corresponding conditions: !(*k &lt; value)
- &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
- false.
-</p></blockquote>
-
-<p>to:</p>
-
-<pre> -2- Returns:
- make_pair(lower_bound(first, last, value),
- upper_bound(first, last, value))
- or
- make_pair(lower_bound(first, last, value, comp),
- upper_bound(first, last, value, comp))
-</pre>
-
-<p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
-
-<blockquote><p>
- -1- Requires: Type T is LessThanComparable
- (lib.lessthancomparable).
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
- -1- Requires: The elements e of [first, last) are partitioned with
- respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
- value) and !comp(value, e). Also, for all elements e of [first,
- last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
- !comp(value, e)
-</p></blockquote>
-
-<p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
-
-
-<p><i>[Redmond: Minor changes in wording. (Removed "non-negative", and
-changed the "other than those described in" wording.) Also, the LWG
-decided to accept the "optional" part.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The proposed resolution reinterprets binary search. Instead of
-thinking about searching for a value in a sorted range, we view that
-as an important special case of a more general algorithm: searching
-for the partition point in a partitioned range.</p>
-
-<p>We also add a guarantee that the old wording did not: we ensure
-that the upper bound is no earlier than the lower bound, that
-the pair returned by equal_range is a valid range, and that the first
-part of that pair is the lower bound.</p>
-
-
-
-
-
-<hr>
-<h3><a name="271"></a>271. basic_iostream missing typedefs</h3>
-<p><b>Section:</b> 27.6.1.5 [iostreamclass] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Class template basic_iostream has no typedefs. The typedefs it
-inherits from its base classes can't be used, since (for example)
-basic_iostream&lt;T&gt;::traits_type is ambiguous.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Add the following to basic_iostream's class synopsis in
-27.6.1.5 [iostreamclass], immediately after <tt>public</tt>:</p>
-
-<pre> // types:
- typedef charT char_type;
- typedef typename traits::int_type int_type;
- typedef typename traits::pos_type pos_type;
- typedef typename traits::off_type off_type;
- typedef traits traits_type;
-</pre>
-
-
-
-
-<hr>
-<h3><a name="272"></a>272. Missing parentheses around subexpression</h3>
-<p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a></p>
-<p><b>Discussion:</b></p>
-<p>
-27.4.4.3, p4 says about the postcondition of the function: If
-rdbuf()!=0 then state == rdstate(); otherwise
-rdstate()==state|ios_base::badbit.
-</p>
-
-<p>
-The expression on the right-hand-side of the operator==() needs to be
-parenthesized in order for the whole expression to ever evaluate to
-anything but non-zero.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add parentheses like so: rdstate()==(state|ios_base::badbit).
-</p>
-
-
-
-
-<hr>
-<h3><a name="273"></a>273. Missing ios_base qualification on members of a dependent class</h3>
-<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
-27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
-That's incorrect since the names are members of a dependent base
-class (14.6.2 [temp.dep]) and thus not visible.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Qualify the names with the name of the class of which they are
-members, i.e., ios_base.</p>
-
-
-
-
-<hr>
-<h3><a name="274"></a>274. a missing/impossible allocator requirement</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-11-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
-any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
-be overloaded on reference and const_reference, which is ill-formed for
-all T = const U. In other words, this won't work:
-</p>
-
-<p>
-template class std::allocator&lt;const int&gt;;
-</p>
-
-<p>
-The obvious solution is to disallow specializations of allocators on
-const types. However, while containers' elements are required to be
-assignable (which rules out specializations on const T's), I think that
-allocators might perhaps be potentially useful for const values in other
-contexts. So if allocators are to allow const types a partial
-specialization of std::allocator&lt;const T&gt; would probably have to be
-provided.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
-
- <blockquote><p>
- any type
- </p></blockquote>
-
-<p>to</p>
- <blockquote><p>
- any non-const, non-reference type
- </p></blockquote>
-
-<p><i>[Redmond: previous proposed resolution was "any non-const,
-non-volatile, non-reference type". Got rid of the "non-volatile".]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Two resolutions were originally proposed: one that partially
-specialized std::allocator for const types, and one that said an
-allocator's value type may not be const. The LWG chose the second.
-The first wouldn't be appropriate, because allocators are intended for
-use by containers, and const value types don't work in containers.
-Encouraging the use of allocators with const value types would only
-lead to unsafe code.
-</p>
-<p>
-The original text for proposed resolution 2 was modified so that it
-also forbids volatile types and reference types.
-</p>
-
-<p><i>[Curaao: LWG double checked and believes volatile is correctly
-excluded from the PR.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="275"></a>275. Wrong type in num_get::get() overloads</h3>
-<p><b>Section:</b> 22.2.2.1.1 [facet.num.get.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2000-11-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.members">issues</a> in [facet.num.get.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
-There are eight overloads, all of which are identical except for the
-last parameter. The overloads are:
-</p>
-<ul>
-<li> long&amp; </li>
-<li> unsigned short&amp; </li>
-<li> unsigned int&amp; </li>
-<li> unsigned long&amp; </li>
-<li> short&amp; </li>
-<li> double&amp; </li>
-<li> long double&amp; </li>
-<li> void*&amp; </li>
-</ul>
-
-<p>
-There is a similar list, in 22.2.2.1.2, of overloads for
-num_get&lt;&gt;::do_get(). In this list, the last parameter has
-the types:
-</p>
-<ul>
-<li> long&amp; </li>
-<li> unsigned short&amp; </li>
-<li> unsigned int&amp; </li>
-<li> unsigned long&amp; </li>
-<li> float&amp; </li>
-<li> double&amp; </li>
-<li> long double&amp; </li>
-<li> void*&amp; </li>
-</ul>
-
-<p>
-These two lists are not identical. They should be, since
-<tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
-the arguments it was given.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.1.1 [facet.num.get.members], change</p>
-<pre> iter_type get(iter_type in, iter_type end, ios_base&amp; str,
- ios_base::iostate&amp; err, short&amp; val) const;
-</pre>
-<p>to</p>
-<pre> iter_type get(iter_type in, iter_type end, ios_base&amp; str,
- ios_base::iostate&amp; err, float&amp; val) const;
-</pre>
-
-
-
-
-<hr>
-<h3><a name="276"></a>276. Assignable requirement for container value type overly strict</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2000-11-07</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-23.1/3 states that the objects stored in a container must be
-Assignable. 23.3.1 [map], paragraph 2,
-states that map satisfies all requirements for a container, while in
-the same time defining value_type as pair&lt;const Key, T&gt; - a type
-that is not Assignable.
-</p>
-
-<p>
-It should be noted that there exists a valid and non-contradictory
-interpretation of the current text. The wording in 23.1/3 avoids
-mentioning value_type, referring instead to "objects stored in a
-container." One might argue that map does not store objects of
-type map::value_type, but of map::mapped_type instead, and that the
-Assignable requirement applies to map::mapped_type, not
-map::value_type.
-</p>
-
-<p>
-However, this makes map a special case (other containers store objects of
-type value_type) and the Assignable requirement is needlessly restrictive in
-general.
-</p>
-
-<p>
-For example, the proposed resolution of active library issue
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
-means that no set operations can exploit the fact that the stored
-objects are Assignable.
-</p>
-
-<p>
-This is related to, but slightly broader than, closed issue
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>23.1/3: Strike the trailing part of the sentence:</p>
- <blockquote><p>
- , and the additional requirements of Assignable types from 23.1/3
- </p></blockquote>
-<p>so that it reads:</p>
- <blockquote><p>
- -3- The type of objects stored in these components must meet the
- requirements of CopyConstructible types (lib.copyconstructible).
- </p></blockquote>
-
-<p>23.1/4: Modify to make clear that this requirement is not for all
-containers. Change to:</p>
-
-<blockquote><p>
--4- Table 64 defines the Assignable requirement. Some containers
-require this property of the types to be stored in the container. T is
-the type used to instantiate the container. t is a value of T, and u is
-a value of (possibly const) T.
-</p></blockquote>
-
-<p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
-CopyConstructible".</p>
-
-<p>23.2.1/2: Add sentence for Assignable requirement. Change to:</p>
-
-<blockquote><p>
--2- A deque satisfies all of the requirements of a container and of a
-reversible container (given in tables in lib.container.requirements) and
-of a sequence, including the optional sequence requirements
-(lib.sequence.reqmts). In addition to the requirements on the stored
-object described in 23.1[lib.container.requirements], the stored object
-must also meet the requirements of Assignable. Descriptions are
-provided here only for operations on deque that are not described in one
-of these tables or for operations where there is additional semantic
-information.
-</p></blockquote>
-
-<p>23.2.2/2: Add Assignable requirement to specific methods of list.
-Change to:</p>
-
-<blockquote>
-<p>-2- A list satisfies all of the requirements of a container and of a
-reversible container (given in two tables in lib.container.requirements)
-and of a sequence, including most of the the optional sequence
-requirements (lib.sequence.reqmts). The exceptions are the operator[]
-and at member functions, which are not provided.
-
-[Footnote: These member functions are only provided by containers whose
-iterators are random access iterators. --- end foonote]
-</p>
-
-<p>list does not require the stored type T to be Assignable unless the
-following methods are instantiated:
-
-[Footnote: Implementors are permitted but not required to take advantage
-of T's Assignable properties for these methods. -- end foonote]
-</p>
-<pre> list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp; x );
- template &lt;class InputIterator&gt;
- void assign(InputIterator first, InputIterator last);
- void assign(size_type n, const T&amp; t);
-</pre>
-
-
-<p>Descriptions are provided here only for operations on list that are not
-described in one of these tables or for operations where there is
-additional semantic information.</p>
-</blockquote>
-
-<p>23.2.4/2: Add sentence for Assignable requirement. Change to:</p>
-
-<blockquote><p>
--2- A vector satisfies all of the requirements of a container and of a
-reversible container (given in two tables in lib.container.requirements)
-and of a sequence, including most of the optional sequence requirements
-(lib.sequence.reqmts). The exceptions are the push_front and pop_front
-member functions, which are not provided. In addition to the
-requirements on the stored object described in
-23.1[lib.container.requirements], the stored object must also meet the
-requirements of Assignable. Descriptions are provided here only for
-operations on vector that are not described in one of these tables or
-for operations where there is additional semantic information.
-</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>list, set, multiset, map, multimap are able to store non-Assignables.
-However, there is some concern about <tt>list&lt;T&gt;</tt>:
-although in general there's no reason for T to be Assignable, some
-implementations of the member functions <tt>operator=</tt> and
-<tt>assign</tt> do rely on that requirement. The LWG does not want
-to forbid such implementations.</p>
-
-<p>Note that the type stored in a standard container must still satisfy
-the requirements of the container's allocator; this rules out, for
-example, such types as "const int". See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>
-for more details.
-</p>
-
-<p>In principle we could also relax the "Assignable" requirement for
-individual <tt>vector</tt> member functions, such as
-<tt>push_back</tt>. However, the LWG did not see great value in such
-selective relaxation. Doing so would remove implementors' freedom to
-implement <tt>vector::push_back</tt> in terms of
-<tt>vector::insert</tt>.</p>
-
-
-
-
-
-<hr>
-<h3><a name="278"></a>278. What does iterator validity mean?</h3>
-<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2000-11-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 23.2.4.4 [list.ops] states that
-</p>
-<pre> void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
-</pre>
-<p>
-<i>invalidates</i> all iterators and references to list <tt>x</tt>.
-</p>
-
-<p>
-But what does the C++ Standard mean by "invalidate"? You
-can still dereference the iterator to a spliced list element, but
-you'd better not use it to delimit a range within the original
-list. For the latter operation, it has definitely lost some of its
-validity.
-</p>
-
-<p>
-If we accept the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>,
-then we'd better clarify that a "valid" iterator need no
-longer designate an element within the same container as it once did.
-We then have to clarify what we mean by invalidating a past-the-end
-iterator, as when a vector or string grows by reallocation. Clearly,
-such an iterator has a different kind of validity. Perhaps we should
-introduce separate terms for the two kinds of "validity."
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add the following text to the end of section 24.1 [iterator.requirements],
-after paragraph 5:</p>
-<blockquote><p>
-An <i>invalid</i> iterator is an iterator that may be
-singular. [Footnote: This definition applies to pointers, since
-pointers are iterators. The effect of dereferencing an iterator that
-has been invalidated is undefined.]
-</p></blockquote>
-
-<p><i>[post-Copenhagen: Matt provided wording.]</i></p>
-
-
-<p><i>[Redmond: General agreement with the intent, some objections to
-the wording. Dave provided new wording.]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>This resolution simply defines a term that the Standard uses but
- never defines, "invalid", in terms of a term that is defined,
- "singular".</p>
-
-<p>Why do we say "may be singular", instead of "is singular"? That's
- becuase a valid iterator is one that is known to be nonsingular.
- Invalidating an iterator means changing it in such a way that it's
- no longer known to be nonsingular. An example: inserting an
- element into the middle of a vector is correctly said to invalidate
- all iterators pointing into the vector. That doesn't necessarily
- mean they all become singular.</p>
-
-
-
-
-
-<hr>
-<h3><a name="280"></a>280. Comparison of reverse_iterator to const reverse_iterator</h3>
-<p><b>Section:</b> 24.4.1 [reverse.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Steve Cleary <b>Date:</b> 2000-11-27</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-This came from an email from Steve Cleary to Fergus in reference to
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
-this in Toronto and believed it should be a separate issue. There was
-also some reservations about whether this was a worthwhile problem to
-fix.
-</p>
-
-<p>
-Steve said: "Fixing reverse_iterator. std::reverse_iterator can
-(and should) be changed to preserve these additional
-requirements." He also said in email that it can be done without
-breaking user's code: "If you take a look at my suggested
-solution, reverse_iterator doesn't have to take two parameters; there
-is no danger of breaking existing code, except someone taking the
-address of one of the reverse_iterator global operator functions, and
-I have to doubt if anyone has ever done that. . . <i>But</i>, just in
-case they have, you can leave the old global functions in as well --
-they won't interfere with the two-template-argument functions. With
-that, I don't see how <i>any</i> user code could break."
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-<b>Section:</b> 24.4.1.1 [reverse.iterator]
-add/change the following declarations:</p>
-<pre> A) Add a templated assignment operator, after the same manner
- as the templated copy constructor, i.e.:
-
- template &lt; class U &gt;
- reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
-
- B) Make all global functions (except the operator+) have
- two template parameters instead of one, that is, for
- operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
-
- template &lt; class Iterator &gt;
- typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
- const reverse_iterator&lt; Iterator &gt;&amp; x,
- const reverse_iterator&lt; Iterator &gt;&amp; y);
-
- with:
-
- template &lt; class Iterator1, class Iterator2 &gt;
- typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
- const reverse_iterator &lt; Iterator1 &gt; &amp; x,
- const reverse_iterator &lt; Iterator2 &gt; &amp; y);
-</pre>
-<p>
-Also make the addition/changes for these signatures in
-24.4.1.3 [reverse.iter.ops].
-</p>
-
-<p><i>[
-Copenhagen: The LWG is concerned that the proposed resolution
-introduces new overloads. Experience shows that introducing
-overloads is always risky, and that it would be inappropriate to
-make this change without implementation experience. It may be
-desirable to provide this feature in a different way.
-]</i></p>
-
-
-<p><i>[
-Lillehammer: We now have implementation experience, and agree that
-this solution is safe and correct.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="281"></a>281. std::min() and max() requirements overly restrictive</h3>
-<p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#486">486</a></p>
-<p><b>Discussion:</b></p>
-<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
-requirements of <tt>LessThanComparable</tt> ( [lessthancomparable])
-and <tt>CopyConstructible</tt> (20.1.1 [utility.arg.requirements]).
-Since the functions take and return their arguments and result by
-const reference, I believe the <tt>CopyConstructible</tt> requirement
-is unnecessary.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
-25.3.7, p1 with</p>
-<p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
-( [lessthancomparable]).
-</p>
-<p>and replace 25.3.7, p4 with</p>
-<p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
-( [lessthancomparable]).
-</p>
-
-
-
-
-<hr>
-<h3><a name="282"></a>282. What types does numpunct grouping refer to?</h3>
-<p><b>Section:</b> 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2000-12-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.put.virtuals">issues</a> in [facet.num.put.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Paragraph 16 mistakenly singles out integral types for inserting
-thousands_sep() characters. This conflicts with the syntax for floating
-point numbers described under 22.2.3.1/2.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change paragraph 16 from:</p>
-
-<blockquote><p>
-For integral types, punct.thousands_sep() characters are inserted into
-the sequence as determined by the value returned by punct.do_grouping()
-using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
-</p></blockquote>
-
-<p>To:</p>
-
-<blockquote><p>
-For arithmetic types, punct.thousands_sep() characters are inserted into
-the sequence as determined by the value returned by punct.do_grouping()
-using the method described in 22.2.3.1.2 [facet.numpunct.virtuals].
-</p></blockquote>
-
-<p><i>[
-Copenhagen: Opinions were divided about whether this is actually an
-inconsistency, but at best it seems to have been unintentional. This
-is only an issue for floating-point output: The standard is
-unambiguous that implementations must parse thousands_sep characters
-when performing floating-point. The standard is also unambiguous that
-this requirement does not apply to the "C" locale.
-]</i></p>
-
-
-<p><i>[
-A survey of existing practice is needed; it is believed that some
-implementations do insert thousands_sep characters for floating-point
-output and others fail to insert thousands_sep characters for
-floating-point input even though this is unambiguously required by the
-standard.
-]</i></p>
-
-
-<p><i>[Post-Curaao: the above proposed resolution is the consensus of
-Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="283"></a>283. std::replace() requirement incorrect/insufficient</h3>
-<p><b>Section:</b> 25.2.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#483">483</a></p>
-<p><b>Discussion:</b></p>
-<p>
-(revision of the further discussion)
-There are a number of problems with the requires clauses for the
-algorithms in 25.1 and 25.2. The requires clause of each algorithm
-should describe the necessary and sufficient requirements on the inputs
-to the algorithm such that the algorithm compiles and runs properly.
-Many of the requires clauses fail to do this. Here is a summary of the kinds
-of mistakes:
-</p>
-
-<ol>
-<li>
-Use of EqualityComparable, which only puts requirements on a single
-type, when in fact an equality operator is required between two
-different types, typically either T and the iterator's value type
-or between the value types of two different iterators.
-</li>
-<li>
-Use of Assignable for T when in fact what was needed is Assignable
-for the value_type of the iterator, and convertability from T to the
-value_type of the iterator. Or for output iterators, the requirement
-should be that T is writable to the iterator (output iterators do
-not have value types).
-</li>
-</ol>
-
-<p>
-Here is the list of algorithms that contain mistakes:
-</p>
-
-<ul>
-<li>25.1.2 std::find</li>
-<li>25.1.6 std::count</li>
-<li>25.1.8 std::equal</li>
-<li>25.1.9 std::search, std::search_n</li>
-<li>25.2.4 std::replace, std::replace_copy</li>
-<li>25.2.5 std::fill</li>
-<li>25.2.7 std::remove, std::remove_copy</li>
-</ul>
-
-<p>
-Also, in the requirements for EqualityComparable, the requirement that
-the operator be defined for const objects is lacking.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>20.1.1 Change p1 from</p>
-
-<p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
-instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
-values of type <tt>T</tt>.
-</p>
-
-<p>to</p>
-
-<p>
-In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
-instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
-values of type <tt>const T</tt>.
-</p>
-
-<p>25 Between p8 and p9</p>
-
-<p>Add the following sentence:</p>
-
-<p>When the description of an algorithm gives an expression such as
-<tt>*first == value</tt> for a condition, it is required that the expression
-evaluate to either true or false in boolean contexts.</p>
-
-<p>25.1.2 Change p1 by deleting the requires clause.</p>
-
-<p>25.1.6 Change p1 by deleting the requires clause.</p>
-
-<p>25.1.9</p>
-
-<p>Change p4 from</p>
-
-<p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
-(20.1.1), type Size is convertible to integral type (4.7.12.3).
-</p>
-
-<p>to</p>
-
-<p>-4- Requires: The type <tt>Size</tt> is convertible to integral
-type (4.7.12.3).</p>
-
-<p>25.2.4 Change p1 from</p>
-
-<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1 ) (and, for <tt>replace()</tt>, <tt>EqualityComparable</tt> (20.1.1 )).</p>
-
-<p>to</p>
-
-<p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
-
-<p>and change p4 from</p>
-
-<p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
-for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
-(20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
-(last - first))</tt> shall not overlap.</p>
-
-<p>to</p>
-
-<p>-4- Requires: The results of the expressions <tt>*first</tt> and
-<tt>new_value</tt> must be writable to the result output iterator. The
-ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
-first))</tt> shall not overlap.</p>
-
-
-<p>25.2.5 Change p1 from</p>
-
-<p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
-type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
-
-<p>to</p>
-
-<p>-1- Requires: The expression <tt>value</tt> must be is writable to
-the output iterator. The type <tt>Size</tt> is convertible to an
-integral type (4.7.12.3).</p>
-
-<p>25.2.7 Change p1 from</p>
-
-<p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
-
-<p>to</p>
-
-<p>
--1- Requires: The value type of the iterator must be
-<tt>Assignable</tt> (23.1).
-</p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-The general idea of the proposed solution is to remove the faulty
-requires clauses and let the returns and effects clauses speak for
-themselves. That is, the returns clauses contain expressions that must
-be valid, and therefore already imply the correct requirements. In
-addition, a sentence is added at the beginning of chapter 25 saying
-that expressions given as conditions must evaluate to true or false in
-a boolean context. An alternative would be to say that the type of
-these condition expressions must be literally bool, but that would be
-imposing a greater restriction that what the standard currently says
-(which is convertible to bool).
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="284"></a>284. unportable example in 20.3.7, p6</h3>
-<p><b>Section:</b> 20.6.7 [comparisons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-26</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The example in 20.6.7 [comparisons], p6 shows how to use the C
-library function <tt>strcmp()</tt> with the function pointer adapter
-<tt>ptr_fun()</tt>. But since it's unspecified whether the C library
-functions have <tt>extern "C"</tt> or <tt>extern
-"C++"</tt> linkage [17.4.2.2 [using.linkage]], and since
-function pointers with different the language linkage specifications
-(7.5 [dcl.link]) are incompatible, whether this example is
-well-formed is unspecified.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 20.6.7 [comparisons] paragraph 6 from:</p>
-<blockquote>
- <p>[<i>Example:</i></p>
- <pre> replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
- </pre>
- <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
-</blockquote>
-
-
-<p>to:</p>
-<blockquote>
- <p>[<i>Example:</i></p>
- <pre> int compare(const char*, const char*);
- replace_if(v.begin(), v.end(),
- not1(bind2nd(ptr_fun(compare), "abc")), "def");
- </pre>
- <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
-</blockquote>
-
-<p>Also, remove footnote 215 in that same paragraph.</p>
-
-<p><i>[Copenhagen: Minor change in the proposed resolution. Since this
-issue deals in part with C and C++ linkage, it was believed to be too
-confusing for the strings in the example to be "C" and "C++".
-]</i></p>
-
-
-<p><i>[Redmond: More minor changes. Got rid of the footnote (which
-seems to make a sweeping normative requirement, even though footnotes
-aren't normative), and changed the sentence after the footnote so that
-it corresponds to the new code fragment.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="285"></a>285. minor editorial errors in fstream ctors</h3>
-<p><b>Section:</b> 27.8.1.7 [ifstream.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2000-12-31</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>27.8.1.7 [ifstream.cons], p2, 27.8.1.11 [ofstream.cons], p2, and
-27.8.1.15 [fstream.cons], p2 say about the effects of each constructor:
-</p>
-
-<p>... If that function returns a null pointer, calls
-<tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
-</p>
-
-<p>The parenthetical note doesn't apply since the ctors cannot throw an
-exception due to the requirement in 27.4.4.1 [basic.ios.cons], p3
-that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Strike the parenthetical note from the Effects clause in each of the
-paragraphs mentioned above.
-</p>
-
-
-
-
-<hr>
-<h3><a name="286"></a>286. &lt;cstdlib&gt; requirements missing size_t typedef</h3>
-<p><b>Section:</b> 25.4 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The &lt;cstdlib&gt; header file contains prototypes for bsearch and
-qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
-prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
-require the typedef size_t. Yet size_t is not listed in the
-&lt;cstdlib&gt; synopsis table 78 in section 25.4.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the type size_t to Table 78 (section 25.4) and add
-the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>
-
-
-
-
-
-<hr>
-<h3><a name="288"></a>288. &lt;cerrno&gt; requirements missing macro EILSEQ</h3>
-<p><b>Section:</b> 19.3 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Judy Ward <b>Date:</b> 2000-12-30</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
-of macros defined in &lt;errno.h&gt; is adjusted to include a new
-macro, EILSEQ"
-</p>
-
-<p>
-ISO/IEC 14882:1998(E) section 19.3 does not refer
-to the above amendment.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Update Table 26 (section 19.3) "Header &lt;cerrno&gt; synopsis"
-and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="291"></a>291. Underspecification of set algorithms</h3>
-<p><b>Section:</b> 25.3.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-01-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.set.operations">issues</a> in [alg.set.operations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The standard library contains four algorithms that compute set
-operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
-<tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>. Each
-of these algorithms takes two sorted ranges as inputs, and writes the
-output of the appropriate set operation to an output range. The elements
-in the output range are sorted.
-</p>
-
-<p>
-The ordinary mathematical definitions are generalized so that they
-apply to ranges containing multiple copies of a given element. Two
-elements are considered to be "the same" if, according to an
-ordering relation provided by the user, neither one is less than the
-other. So, for example, if one input range contains five copies of an
-element and another contains three, the output range of <tt>set_union</tt>
-will contain five copies, the output range of
-<tt>set_intersection</tt> will contain three, the output range of
-<tt>set_difference</tt> will contain two, and the output range of
-<tt>set_symmetric_difference</tt> will contain two.
-</p>
-
-<p>
-Because two elements can be "the same" for the purposes
-of these set algorithms, without being identical in other respects
-(consider, for example, strings under case-insensitive comparison),
-this raises a number of unanswered questions:
-</p>
-
-<ul>
-<li>If we're copying an element that's present in both of the
-input ranges, which one do we copy it from?</li>
-<li>If there are <i>n</i> copies of an element in the relevant
-input range, and the output range will contain fewer copies (say
-<i>m</i>) which ones do we choose? The first <i>m</i>, or the last
-<i>m</i>, or something else?</li>
-<li>Are these operations stable? That is, does a run of equivalent
-elements appear in the output range in the same order as as it
-appeared in the input range(s)?</li>
-</ul>
-
-<p>
-The standard should either answer these questions, or explicitly
-say that the answers are unspecified. I prefer the former option,
-since, as far as I know, all existing implementations behave the
-same way.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Add the following to the end of 25.3.5.2 [set.union] paragraph 5:</p>
-<blockquote><p>
-If [first1, last1) contains <i>m</i> elements that are equivalent to
-each other and [first2, last2) contains <i>n</i> elements that are
-equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
-will be copied to the output range: all <i>m</i> of these elements
-from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
-[first2, last2), in that order.
-</p></blockquote>
-
-<p>Add the following to the end of 25.3.5.3 [set.intersection] paragraph 5:</p>
-<blockquote><p>
-If [first1, last1) contains <i>m</i> elements that are equivalent to each
-other and [first2, last2) contains <i>n</i> elements that are
-equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
-elements from [first1, last1) are copied to the output range.
-</p></blockquote>
-
-<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 [set.difference]
-paragraph 4:</p>
-<blockquote><p>
-If [first1, last1) contains <i>m</i> elements that are equivalent to each
-other and [first2, last2) contains <i>n</i> elements that are
-equivalent to them, the last max(<i>m-n</i>, 0) elements from
-[first1, last1) are copied to the output range.
-</p></blockquote>
-
-<p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 [set.symmetric.difference]
-paragraph 4:</p>
-<blockquote><p>
-If [first1, last1) contains <i>m</i> elements that are equivalent to
-each other and [first2, last2) contains <i>n</i> elements that are
-equivalent to them, then |<i>m - n</i>| of those elements will be
-copied to the output range: the last <i>m - n</i> of these elements
-from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
-m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
-</p></blockquote>
-
-<p><i>[Santa Cruz: it's believed that this language is clearer than
- what's in the Standard. However, it's also believed that the
- Standard may already make these guarantees (although not quite in
- these words). Bill and Howard will check and see whether they think
- that some or all of these changes may be redundant. If so, we may
- close this issue as NAD.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>For simple cases, these descriptions are equivalent to what's
- already in the Standard. For more complicated cases, they describe
- the behavior of existing implementations.</p>
-
-
-
-
-
-<hr>
-<h3><a name="292"></a>292. effects of a.copyfmt (a)</h3>
-<p><b>Section:</b> 27.4.4.2 [basic.ios.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.ios.members">active issues</a> in [basic.ios.members].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.ios.members">issues</a> in [basic.ios.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The Effects clause of the member function <tt>copyfmt()</tt> in
-27.4.4.2, p15 doesn't consider the case where the left-hand side
-argument is identical to the argument on the right-hand side, that is
-<tt>(this == &amp;rhs)</tt>. If the two arguments are identical there
-is no need to copy any of the data members or call any callbacks
-registered with <tt>register_callback()</tt>. Also, as Howard Hinnant
-points out in message c++std-lib-8149 it appears to be incorrect to
-allow the object to fire <tt>erase_event</tt> followed by
-<tt>copyfmt_event</tt> since the callback handling the latter event
-may inadvertently attempt to access memory freed by the former.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the Effects clause in 27.4.4.2, p15 from</p>
-
-<blockquote><p>
-<b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
-the corresponding member objects of <tt>rhs</tt>, except that...
-</p></blockquote>
-
-<p>to</p>
-
-<blockquote><p>
-<b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
-assigns to the member objects of <tt>*this</tt> the corresponding member
-objects of <tt>rhs</tt>, except that...
-</p></blockquote>
-
-
-
-
-<hr>
-<h3><a name="294"></a>294. User defined macros and standard headers</h3>
-<p><b>Section:</b> 17.4.3.2.1 [macro.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> James Kanze <b>Date:</b> 2001-01-11</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Paragraph 2 of 17.4.3.2.1 [macro.names] reads: "A
-translation unit that includes a header shall not contain any macros
-that define names declared in that header." As I read this, it
-would mean that the following program is legal:</p>
-
-<pre> #define npos 3.14
- #include &lt;sstream&gt;
-</pre>
-
-<p>since npos is not defined in &lt;sstream&gt;. It is, however, defined
-in &lt;string&gt;, and it is hard to imagine an implementation in
-which &lt;sstream&gt; didn't include &lt;string&gt;.</p>
-
-<p>I think that this phrase was probably formulated before it was
-decided that a standard header may freely include other standard
-headers. The phrase would be perfectly appropriate for C, for
-example. In light of 17.4.4.1 [res.on.headers] paragraph 1, however,
-it isn't stringent enough.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>For 17.4.3.2.1 [macro.names], replace the current wording, which reads:</p>
-<blockquote>
- <p>Each name defined as a macro in a header is reserved to the
- implementation for any use if the translation unit includes
- the header.168)</p>
-
- <p>A translation unit that includes a header shall not contain any
- macros that define names declared or defined in that header. Nor shall
- such a translation unit define macros for names lexically
- identical to keywords.</p>
-
- <p>168) It is not permissible to remove a library macro definition by
- using the #undef directive.</p>
-</blockquote>
-
-<p>with the wording:</p>
-
-<blockquote>
- <p>A translation unit that includes a standard library header shall not
- #define or #undef names declared in any standard library header.</p>
-
- <p>A translation unit shall not #define or #undef names lexically
- identical to keywords.</p>
-</blockquote>
-
-<p><i>[Lillehammer: Beman provided new wording]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="295"></a>295. Is abs defined in &lt;cmath&gt;?</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2001-01-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Table 80 lists the contents of the &lt;cmath&gt; header. It does not
-list <tt>abs()</tt>. However, 26.5, paragraph 6, which lists added
-signatures present in &lt;cmath&gt;, does say that several overloads
-of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add <tt>abs</tt> to Table 80. Also, remove the parenthetical list
-of functions "(abs(), div(), rand(), srand())" from 26.5 [numarray],
-paragraph 1.
-</p>
-
-<p><i>[Copenhagen: Modified proposed resolution so that it also gets
-rid of that vestigial list of functions in paragraph 1.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>All this DR does is fix a typo; it's uncontroversial. A
-separate question is whether we're doing the right thing in
-putting some overloads in &lt;cmath&gt; that we aren't also
-putting in &lt;cstdlib&gt;. That's issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</p>
-
-
-
-
-
-<hr>
-<h3><a name="297"></a>297. const_mem_fun_t&lt;&gt;::argument_type should be const T*</h3>
-<p><b>Section:</b> 20.6.8 [logical.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The class templates <tt>const_mem_fun_t</tt> in 20.5.8, p8 and
-<tt>const_mem_fun1_t</tt>
-in 20.5.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
-<tt>binary_function&lt;T*,
-A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
-<tt>first_argument_type</tt>
-members, respectively, are both defined to be <tt>T*</tt> (non-const).
-However, their function call member operator takes a <tt>const T*</tt>
-argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
-T*</tt> instead, so that one can easily refer to it in generic code. The
-example below derived from existing code fails to compile due to the
-discrepancy:
-</p>
-
-<p><tt>template &lt;class T&gt;</tt>
-<br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
-<br><tt>{</tt>
-<br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
-T::argument_type)
-const =&nbsp;&nbsp; // #2</tt>
-<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
-<br><tt>}</tt>
-</p>
-
-<p><tt>struct X { /* ... */ };</tt></p>
-
-<p><tt>int main ()</tt>
-<br><tt>{</tt>
-<br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
-<br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
-&gt;(&amp;x);&nbsp;&nbsp;
-// #3</tt>
-<br><tt>}</tt>
-</p>
-
-<p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
-<br>#2 the type of the pointer is incompatible with the type of the member
-function
-<br>#3 the address of a constant being passed to a function taking a non-const
-<tt>X*</tt>
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace the top portion of the definition of the class template
-const_mem_fun_t in 20.5.8, p8
-</p>
-<p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
-<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
-unary_function&lt;T*, S&gt; {</tt>
-</p>
-<p>with</p>
-<p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
-<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
-unary_function&lt;<b>const</b> T*, S&gt; {</tt>
-</p>
-<p>Also replace the top portion of the definition of the class template
-const_mem_fun1_t in 20.5.8, p9</p>
-<p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
-<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
-binary_function&lt;T*, A, S&gt; {</tt>
-</p>
-<p>with</p>
-<p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
-<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
-binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
-and the argument type itself, are not the same.</p>
-
-
-
-
-
-<hr>
-<h3><a name="298"></a>298. ::operator delete[] requirement incorrect/insufficient</h3>
-<p><b>Section:</b> 18.5.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> John A. Pedretti <b>Date:</b> 2001-01-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 -
-namely that for non-null value of <i>ptr</i>, the operator reclaims storage
-allocated by the earlier call to the default <tt>operator new[]</tt> - is not
-correct in all cases. Since the specified <tt>operator new[]</tt> default
-behavior is to call <tt>operator new</tt> (18.5.1.2, p4, p8), which can be
-replaced, along with <tt>operator delete</tt>, by the user, to implement their
-own memory management, the specified default behavior of<tt> operator
-delete[]</tt> must be to call <tt>operator delete</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 18.5.1.2, p12 from</p>
-<blockquote><p>
-<b>-12-</b> <b>Default behavior:</b></p>
-<ul>
-<li>
-For a null value of <i><tt>ptr</tt></i> , does nothing.
-</li>
-<li>
-Any other value of <i><tt>ptr</tt></i> shall be a value returned
-earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
-[Footnote: The value must not have been invalidated by an intervening
-call to <tt>operator delete[](void*)</tt> (17.4.3.8 [res.on.arguments]).
---- end footnote]
-For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
-allocated by the earlier call to the default <tt>operator new[]</tt>.
-</li>
-</ul>
-</blockquote>
-
-<p>to</p>
-
-<blockquote><p>
-<b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
-delete(</tt><i>ptr</i>)
-or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
-</p></blockquote>
-<p>and expunge paragraph 13.</p>
-
-
-
-
-<hr>
-<h3><a name="300"></a>300. list::merge() specification incomplete</h3>
-<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> John Pedretti <b>Date:</b> 2001-01-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The "Effects" clause for list::merge() (23.2.4.4 [list.ops], p23)
-appears to be incomplete: it doesn't cover the case where the argument
-list is identical to *this (i.e., this == &amp;x). The requirement in the
-note in p24 (below) is that x be empty after the merge which is surely
-unintended in this case.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 23.2.4.4 [list.ops], replace paragraps 23-25 with:</p>
-<blockquote>
-<p>
-23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
-sorted ranges [begin(), end()) and [x.begin(), x.end()). The result
-is a range in which the elements will be sorted in non-decreasing
-order according to the ordering defined by comp; that is, for every
-iterator i in the range other than the first, the condition comp(*i,
-*(i - 1)) will be false.
-</p>
-
-<p>
-24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
-two original ranges, the elements from the original range [begin(),
-end()) always precede the elements from the original range [x.begin(),
-x.end()). If (&amp;x != this) the range [x.begin(), x.end()) is empty
-after the merge.
-</p>
-
-<p>
-25 Complexity: At most size() + x.size() - 1 applications of comp if
-(&amp;x ! = this); otherwise, no applications of comp are performed. If
-an exception is thrown other than by a comparison there are no
-effects.
-</p>
-
-</blockquote>
-
-<p><i>[Copenhagen: The original proposed resolution did not fix all of
-the problems in 23.2.4.4 [list.ops], p22-25. Three different
-paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
-Changing p23, without changing the other two, appears to introduce
-contradictions. Additionally, "merges the argument list into the
-list" is excessively vague.]</i></p>
-
-
-<p><i>[Post-Curaao: Robert Klarer provided new wording.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="301"></a>301. basic_string template ctor effects clause omits allocator argument</h3>
-<p><b>Section:</b> 21.3.1 [string.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-01-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.require">issues</a> in [string.require].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The effects clause for the basic_string template ctor in 21.3.1, p15
-leaves out the third argument of type Allocator. I believe this to be
-a mistake.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace</p>
-
-<blockquote>
- <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
- type, equivalent to</p>
-
- <blockquote><p><tt>basic_string(static_cast&lt;size_type&gt;(begin),
- static_cast&lt;value_type&gt;(end))</tt></p></blockquote>
-</blockquote>
-
-<p>with</p>
-
-<blockquote>
- <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
- type, equivalent to</p>
-
- <blockquote><p><tt>basic_string(static_cast&lt;size_type&gt;(begin),
- static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></p></blockquote>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="303"></a>303. Bitset input operator underspecified</h3>
-<p><b>Section:</b> 23.3.5.3 [bitset.operators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-02-05</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
-"Extracts up to <i>N</i> (single-byte) characters from
-<i>is</i>.", where <i>is</i> is a stream of type
-<tt>basic_istream&lt;charT, traits&gt;</tt>.
-</p>
-
-<p>
-The standard does not say what it means to extract single byte
-characters from a stream whose character type, <tt>charT</tt>, is in
-general not a single-byte character type. Existing implementations
-differ.
-</p>
-
-<p>
-A reasonable solution will probably involve <tt>widen()</tt> and/or
-<tt>narrow()</tt>, since they are the supplied mechanism for
-converting a single character between <tt>char</tt> and
-arbitrary <tt>charT</tt>.
-</p>
-
-<p>Narrowing the input characters is not the same as widening the
-literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
-locales in which more than one wide character maps to the narrow
-character <tt>'0'</tt>. Narrowing means that alternate
-representations may be used for bitset input, widening means that
-they may not be.</p>
-
-<p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
-(22.2.2.1.2/8) compares input characters to widened version of narrow
-character literals.</p>
-
-<p>From Pete Becker, in c++std-lib-8224:</p>
-<blockquote>
-<p>
-Different writing systems can have different representations for the
-digits that represent 0 and 1. For example, in the Unicode representation
-of the Devanagari script (used in many of the Indic languages) the digit 0
-is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
-into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
-0x0031 for for the Latin representations of '0' and '1', as well as code
-points for the same numeric values in several other scripts (Tamil has no
-character for 0, but does have the digits 1-9), and any of these values
-would also be narrowed to '0' and '1'.
-</p>
-
-<p>...</p>
-
-<p>
-It's fairly common to intermix both native and Latin
-representations of numbers in a document. So I think the rule has to be
-that if a wide character represents a digit whose value is 0 then the bit
-should be cleared; if it represents a digit whose value is 1 then the bit
-should be set; otherwise throw an exception. So in a Devanagari locale,
-both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
-would set it. Widen can't do that. It would pick one of those two values,
-and exclude the other one.
-</p>
-
-</blockquote>
-
-<p>From Jens Maurer, in c++std-lib-8233:</p>
-
-<blockquote>
-<p>
-Whatever we decide, I would find it most surprising if
-bitset conversion worked differently from int conversion
-with regard to alternate local representations of
-numbers.
-</p>
-
-<p>Thus, I think the options are:</p>
-<ul>
- <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
-require the use of narrow().</li>
-
- <li> Have a defect issue for bitset() which describes clearly
-that widen() is to be used.</li>
-</ul>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
- <p>Replace the first two sentences of paragraph 5 with:</p>
-
- <blockquote><p>
- Extracts up to <i>N</i> characters from <i>is</i>. Stores these
- characters in a temporary object <i>str</i> of type
- <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
- expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
- </p></blockquote>
-
- <p>Replace the third bullet item in paragraph 5 with:</p>
- <ul><li>
- the next input character is neither <tt><i>is</i>.widen(0)</tt>
- nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
- is not extracted).
- </li></ul>
-
-
-
-<p><b>Rationale:</b></p>
-<p>Input for <tt>bitset</tt> should work the same way as numeric
-input. Using <tt>widen</tt> does mean that alternative digit
-representations will not be recognized, but this was a known
-consequence of the design choice.</p>
-
-
-
-
-
-<hr>
-<h3><a name="305"></a>305. Default behavior of codecvt&lt;wchar_t, char, mbstate_t&gt;::length()</h3>
-<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-01-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>22.2.1.5/3 introduces codecvt in part with:</p>
-
-<blockquote><p>
- codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
- character sets for tiny and wide characters. Instantiations on
- mbstate_t perform conversion between encodings known to the library
- implementor.
-</p></blockquote>
-
-<p>But 22.2.1.5.2/10 describes do_length in part with:</p>
-
-<blockquote><p>
- ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and
- (from_end-from).
-</p></blockquote>
-
-<p>
-The semantics of do_in and do_length are linked. What one does must
-be consistent with what the other does. 22.2.1.5/3 leads me to
-believe that the vendor is allowed to choose the algorithm that
-codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
-his customers happy on a given platform. But 22.2.1.5.2/10 explicitly
-says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
-return. And thus indirectly specifies the algorithm that
-codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform. I believe
-that this is not what was intended and is a defect.
-</p>
-
-<p>Discussion from the -lib reflector:
-
-<br>This proposal would have the effect of making the semantics of
-all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
-mbstate_t&gt;</tt> implementation specified. Is that what we want, or
-do we want to mandate specific behavior for the base class virtuals
-and leave the implementation specified behavior for the codecvt_byname
-derived class? The tradeoff is that former allows implementors to
-write a base class that actually does something useful, while the
-latter gives users a way to get known and specified---albeit
-useless---behavior, and is consistent with the way the standard
-handles other facets. It is not clear what the original intention
-was.</p>
-
-<p>
-Nathan has suggest a compromise: a character that is a widened version
-of the characters in the basic execution character set must be
-converted to a one-byte sequence, but there is no such requirement
-for characters that are not part of the basic execution character set.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 22.2.1.5.2/5 from:
-</p>
-<p>
-The instantiations required in Table 51 (lib.locale.category), namely
-codecvt&lt;wchar_t,char,mbstate_t&gt; and
-codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
-than (to_limit-to) destination elements. It always leaves the to_next
-pointer pointing one beyond the last element successfully stored.
-</p>
-<p>
-to:
-</p>
-<p>
-Stores no more than (to_limit-to) destination elements, and leaves the
-to_next pointer pointing one beyond the last element successfully
-stored. codecvt&lt;char,char,mbstate_t&gt; stores no characters.
-</p>
-
-<p>Change 22.2.1.5.2/10 from:</p>
-
-<blockquote><p>
--10- Returns: (from_next-from) where from_next is the largest value in
-the range [from,from_end] such that the sequence of values in the
-range [from,from_next) represents max or fewer valid complete
-characters of type internT. The instantiations required in Table 51
-(21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
-codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
-(from_end-from).
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
--10- Returns: (from_next-from) where from_next is the largest value in
-the range [from,from_end] such that the sequence of values in the range
-[from,from_next) represents max or fewer valid complete characters of
-type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns
-the lesser of max and (from_end-from).
-</p></blockquote>
-
-<p><i>[Redmond: Nathan suggested an alternative resolution: same as
-above, but require that, in the default encoding, a character from the
-basic execution character set would map to a single external
-character. The straw poll was 8-1 in favor of the proposed
-resolution.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The default encoding should be whatever users of a given platform
-would expect to be the most natural. This varies from platform to
-platform. In many cases there is a preexisting C library, and users
-would expect the default encoding to be whatever C uses in the default
-"C" locale. We could impose a guarantee like the one Nathan suggested
-(a character from the basic execution character set must map to a
-single external character), but this would rule out important
-encodings that are in common use: it would rule out JIS, for
-example, and it would rule out a fixed-width encoding of UCS-4.</p>
-
-<p><i>[Curaao: fixed rationale typo at the request of Ichiro Koshida;
-"shift-JIS" changed to "JIS".]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="306"></a>306. offsetof macro and non-POD types</h3>
-<p><b>Section:</b> 18.1 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 2001-02-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
-
-<p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
-accepts a restricted set of <i>type</i> arguments in this
-International Standard. <i>type</i> shall be a POD structure or a POD
-union (clause 9). The result of applying the offsetof macro to a field
-that is a static data member or a function member is
-undefined."</p>
-
-<p>For the POD requirement, it doesn't say "no diagnostic
-required" or "undefined behavior". I read 1.4 [intro.compliance], paragraph 1, to mean that a diagnostic is required.
-It's not clear whether this requirement was intended. While it's
-possible to provide such a diagnostic, the extra complication doesn't
-seem to add any value.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
-structure or a POD union the results are undefined."</p>
-
-<p><i>[Copenhagen: straw poll was 7-4 in favor. It was generally
-agreed that requiring a diagnostic was inadvertent, but some LWG
-members thought that diagnostics should be required whenever
-possible.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="307"></a>307. Lack of reference typedefs in container adaptors</h3>
-<p><b>Section:</b> 23.2.4 [list] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-03-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>From reflector message c++std-lib-8330. See also lib-8317.</p>
-
-<p>
-The standard is currently inconsistent in 23.2.4.2 [list.capacity]
-paragraph 1 and 23.2.4.3 [list.modifiers] paragraph 1.
-23.2.3.3/1, for example, says:
-</p>
-
-<blockquote><p>
--1- Any sequence supporting operations back(), push_back() and pop_back()
-can be used to instantiate stack. In particular, vector (lib.vector), list
-(lib.list) and deque (lib.deque) can be used.
-</p></blockquote>
-
-<p>But this is false: vector&lt;bool&gt; can not be used, because the
-container adaptors return a T&amp; rather than using the underlying
-container's reference type.</p>
-
-<p>This is a contradiction that can be fixed by:</p>
-
-<ol>
-<li>Modifying these paragraphs to say that vector&lt;bool&gt;
- is an exception.</li>
-<li>Removing the vector&lt;bool&gt; specialization.</li>
-<li>Changing the return types of stack and priority_queue to use
- reference typedef's.</li>
-</ol>
-
-<p>
-I propose 3. This does not preclude option 2 if we choose to do it
-later (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>); the issues are independent. Option
-3 offers a small step towards support for proxied containers. This
-small step fixes a current contradiction, is easy for vendors to
-implement, is already implemented in at least one popular lib, and
-does not break any code.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Summary: Add reference and const_reference typedefs to queue,
-priority_queue and stack. Change return types of "value_type&amp;" to
-"reference". Change return types of "const value_type&amp;" to
-"const_reference". Details:</p>
-
-<p>Change 23.2.3.1/1 from:</p>
-
-<pre> namespace std {
- template &lt;class T, class Container = deque&lt;T&gt; &gt;
- class queue {
- public:
- typedef typename Container::value_type value_type;
- typedef typename Container::size_type size_type;
- typedef Container container_type;
- protected:
- Container c;
-
- public:
- explicit queue(const Container&amp; = Container());
-
- bool empty() const { return c.empty(); }
- size_type size() const { return c.size(); }
- value_type&amp; front() { return c.front(); }
- const value_type&amp; front() const { return c.front(); }
- value_type&amp; back() { return c.back(); }
- const value_type&amp; back() const { return c.back(); }
- void push(const value_type&amp; x) { c.push_back(x); }
- void pop() { c.pop_front(); }
- };
-</pre>
-
-<p>to:</p>
-
-<pre> namespace std {
- template &lt;class T, class Container = deque&lt;T&gt; &gt;
- class queue {
- public:
- typedef typename Container::value_type value_type;
- typedef typename Container::reference reference;
- typedef typename Container::const_reference const_reference;
- typedef typename Container::value_type value_type;
- typedef typename Container::size_type size_type;
- typedef Container container_type;
- protected:
- Container c;
-
- public:
- explicit queue(const Container&amp; = Container());
-
- bool empty() const { return c.empty(); }
- size_type size() const { return c.size(); }
- reference front() { return c.front(); }
- const_reference front() const { return c.front(); }
- reference back() { return c.back(); }
- const_reference back() const { return c.back(); }
- void push(const value_type&amp; x) { c.push_back(x); }
- void pop() { c.pop_front(); }
- };
-</pre>
-
-<p>Change 23.2.3.2/1 from:</p>
-
-<pre> namespace std {
- template &lt;class T, class Container = vector&lt;T&gt;,
- class Compare = less&lt;typename Container::value_type&gt; &gt;
- class priority_queue {
- public:
- typedef typename Container::value_type value_type;
- typedef typename Container::size_type size_type;
- typedef Container container_type;
- protected:
- Container c;
- Compare comp;
-
- public:
- explicit priority_queue(const Compare&amp; x = Compare(),
- const Container&amp; = Container());
- template &lt;class InputIterator&gt;
- priority_queue(InputIterator first, InputIterator last,
- const Compare&amp; x = Compare(),
- const Container&amp; = Container());
-
- bool empty() const { return c.empty(); }
- size_type size() const { return c.size(); }
- const value_type&amp; top() const { return c.front(); }
- void push(const value_type&amp; x);
- void pop();
- };
- // no equality is provided
- }
-</pre>
-
-<p>to:</p>
-
-<pre> namespace std {
- template &lt;class T, class Container = vector&lt;T&gt;,
- class Compare = less&lt;typename Container::value_type&gt; &gt;
- class priority_queue {
- public:
- typedef typename Container::value_type value_type;
- typedef typename Container::reference reference;
- typedef typename Container::const_reference const_reference;
- typedef typename Container::size_type size_type;
- typedef Container container_type;
- protected:
- Container c;
- Compare comp;
-
- public:
- explicit priority_queue(const Compare&amp; x = Compare(),
- const Container&amp; = Container());
- template &lt;class InputIterator&gt;
- priority_queue(InputIterator first, InputIterator last,
- const Compare&amp; x = Compare(),
- const Container&amp; = Container());
-
- bool empty() const { return c.empty(); }
- size_type size() const { return c.size(); }
- const_reference top() const { return c.front(); }
- void push(const value_type&amp; x);
- void pop();
- };
- // no equality is provided
- }
-</pre>
-
-<p>And change 23.2.3.3/1 from:</p>
-
-<pre> namespace std {
- template &lt;class T, class Container = deque&lt;T&gt; &gt;
- class stack {
- public:
- typedef typename Container::value_type value_type;
- typedef typename Container::size_type size_type;
- typedef Container container_type;
- protected:
- Container c;
-
- public:
- explicit stack(const Container&amp; = Container());
-
- bool empty() const { return c.empty(); }
- size_type size() const { return c.size(); }
- value_type&amp; top() { return c.back(); }
- const value_type&amp; top() const { return c.back(); }
- void push(const value_type&amp; x) { c.push_back(x); }
- void pop() { c.pop_back(); }
- };
-
- template &lt;class T, class Container&gt;
- bool operator==(const stack&lt;T, Container&gt;&amp; x,
- const stack&lt;T, Container&gt;&amp; y);
- template &lt;class T, class Container&gt;
- bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
- const stack&lt;T, Container&gt;&amp; y);
- template &lt;class T, class Container&gt;
- bool operator!=(const stack&lt;T, Container&gt;&amp; x,
- const stack&lt;T, Container&gt;&amp; y);
- template &lt;class T, class Container&gt;
- bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
- const stack&lt;T, Container&gt;&amp; y);
- template &lt;class T, class Container&gt;
- bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
- const stack&lt;T, Container&gt;&amp; y);
- template &lt;class T, class Container&gt;
- bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
- const stack&lt;T, Container&gt;&amp; y);
- }
-</pre>
-
-<p>to:</p>
-
-<pre> namespace std {
- template &lt;class T, class Container = deque&lt;T&gt; &gt;
- class stack {
- public:
- typedef typename Container::value_type value_type;
- typedef typename Container::reference reference;
- typedef typename Container::const_reference const_reference;
- typedef typename Container::size_type size_type;
- typedef Container container_type;
- protected:
- Container c;
-
- public:
- explicit stack(const Container&amp; = Container());
-
- bool empty() const { return c.empty(); }
- size_type size() const { return c.size(); }
- reference top() { return c.back(); }
- const_reference top() const { return c.back(); }
- void push(const value_type&amp; x) { c.push_back(x); }
- void pop() { c.pop_back(); }
- };
-
- template &lt;class T, class Container&gt;
- bool operator==(const stack&lt;T, Container&gt;&amp; x,
- const stack&lt;T, Container&gt;&amp; y);
- template &lt;class T, class Container&gt;
- bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
- const stack&lt;T, Container&gt;&amp; y);
- template &lt;class T, class Container&gt;
- bool operator!=(const stack&lt;T, Container&gt;&amp; x,
- const stack&lt;T, Container&gt;&amp; y);
- template &lt;class T, class Container&gt;
- bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
- const stack&lt;T, Container&gt;&amp; y);
- template &lt;class T, class Container&gt;
- bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
- const stack&lt;T, Container&gt;&amp; y);
- template &lt;class T, class Container&gt;
- bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
- const stack&lt;T, Container&gt;&amp; y);
- }
-</pre>
-
-<p><i>[Copenhagen: This change was discussed before the IS was released
-and it was deliberately not adopted. Nevertheless, the LWG believes
-(straw poll: 10-2) that it is a genuine defect.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="308"></a>308. Table 82 mentions unrelated headers</h3>
-<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
-streams (27.7 [string.streams]) and the headers &lt;cstdio&gt; and
-&lt;cwchar&gt; for File streams (27.8 [file.streams]). It's not clear
-why these headers are mentioned in this context since they do not
-define any of the library entities described by the
-subclauses. According to 17.4.1.1 [contents], only such headers
-are to be listed in the summary.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
-Table 82.</p>
-
-<p><i>[Copenhagen: changed the proposed resolution slightly. The
-original proposed resolution also said to remove &lt;cstdio&gt; from
-Table 82. However, &lt;cstdio&gt; is mentioned several times within
-section 27.8 [file.streams], including 27.8.2 [c.files].]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="310"></a>310. Is errno a macro?</h3>
-<p><b>Section:</b> 17.4.1.2 [headers], 19.3 [errno] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 2001-03-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
- Exactly how should errno be declared in a conforming C++ header?
- </p>
-
- <p>
- The C standard says in 7.1.4 that it is unspecified whether errno is a
- macro or an identifier with external linkage. In some implementations
- it can be either, depending on compile-time options. (E.g., on
- Solaris in multi-threading mode, errno is a macro that expands to a
- function call, but is an extern int otherwise. "Unspecified" allows
- such variability.)
- </p>
-
- <p>The C++ standard:</p>
- <ul>
- <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
- <li>17.4.3.1.3 footnote 166 says errno is reserved as an external
- name (true), and implies that it is an identifier.</li>
- <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
- on to say that the contents of of C++ &lt;errno.h&gt; are the
- same as in C, begging the question.</li>
- <li>C.2, table 95 lists errno as a macro, without comment.</li>
- </ul>
-
- <p>I find no other references to errno.</p>
-
- <p>We should either explicitly say that errno must be a macro, even
- though it need not be a macro in C, or else explicitly leave it
- unspecified. We also need to say something about namespace std.
- A user who includes &lt;cerrno&gt; needs to know whether to write
- <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
- else &lt;cerrno&gt; is useless.</p>
-
- <p>Two acceptable fixes:</p>
- <ul>
- <li><p>errno must be a macro. This is trivially satisfied by adding<br>
- &nbsp;&nbsp;#define errno (::std::errno)<br>
- to the headers if errno is not already a macro. You then always
- write errno without any scope qualification, and it always expands
- to a correct reference. Since it is always a macro, you know to
- avoid using errno as a local identifer.</p></li>
- <li><p>errno is in the global namespace. This fix is inferior, because
- ::errno is not guaranteed to be well-formed.</p></li>
- </ul>
-
- <p><i>[
- This issue was first raised in 1999, but it slipped through
- the cracks.
- ]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
- <p>Change the Note in section 17.4.1.2p5 from</p>
-
- <blockquote><p>
- Note: the names defined as macros in C include the following:
- assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
- </p></blockquote>
-
- <p>to</p>
-
- <blockquote><p>
- Note: the names defined as macros in C include the following:
- assert, offsetof, setjmp, va_arg, va_end, and va_start.
- </p></blockquote>
-
- <p>In section 19.3, change paragraph 2 from</p>
-
- <blockquote><p>
- The contents are the same as the Standard C library header
- &lt;errno.h&gt;.
- </p></blockquote>
-
- <p>to</p>
-
- <blockquote><p>
- The contents are the same as the Standard C library header
- &lt;errno.h&gt;, except that errno shall be defined as a macro.
- </p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>C++ must not leave it up to the implementation to decide whether or
-not a name is a macro; it must explicitly specify exactly which names
-are required to be macros. The only one that really works is for it
-to be a macro.</p>
-
-<p><i>[Curaao: additional rationale added.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="311"></a>311. Incorrect wording in basic_ostream class synopsis</h3>
-<p><b>Section:</b> 27.6.2.1 [ostream] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-03-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream">issues</a> in [ostream].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>In 27.6.2.1 [ostream], the synopsis of class basic_ostream says:</p>
-
-<pre> // partial specializationss
- template&lt;class traits&gt;
- basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
- const char * );
-</pre>
-
-<p>Problems:</p>
-<ul>
-<li>Too many 's's at the end of "specializationss" </li>
-<li>This is an overload, not a partial specialization</li>
-</ul>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In the synopsis in 27.6.2.1 [ostream], remove the
-<i>// partial specializationss</i> comment. Also remove the same
-comment (correctly spelled, but still incorrect) from the synopsis in
-27.6.2.6.4 [ostream.inserters.character].
-</p>
-
-<p><i>[
-Pre-Redmond: added 27.6.2.6.4 [ostream.inserters.character] because of Martin's
-comment in c++std-lib-8939.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="312"></a>312. Table 27 is missing headers</h3>
-<p><b>Section:</b> 20 [utilities] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-03-29</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
-Memory (lib.memory) but neglects to mention the headers
-&lt;cstdlib&gt; and &lt;cstring&gt; that are discussed in 20.5.5 [meta.rel].</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
-as &lt;memory&gt;.</p>
-
-
-
-
-
-<hr>
-<h3><a name="315"></a>315. Bad "range" in list::unique complexity</h3>
-<p><b>Section:</b> 23.2.4.4 [list.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-05-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.ops">issues</a> in [list.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-23.2.4.4 [list.ops], Para 21 describes the complexity of
-list::unique as: "If the range (last - first) is not empty, exactly
-(last - first) -1 applications of the corresponding predicate,
-otherwise no applications of the predicate)".
-</p>
-
-<p>
-"(last - first)" is not a range.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the "range" from (last - first) to [first, last).
-</p>
-
-
-
-
-<hr>
-<h3><a name="316"></a>316. Vague text in Table 69</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Table 69 says this about a_uniq.insert(t):</p>
-
-<blockquote><p>
-inserts t if and only if there is no element in the container with key
-equivalent to the key of t. The bool component of the returned pair
-indicates whether the insertion takes place and the iterator component of the
-pair points to the element with key equivalent to the key of t.
-</p></blockquote>
-
-<p>The description should be more specific about exactly how the bool component
-indicates whether the insertion takes place.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the text in question to</p>
-
-<blockquote><p>
-...The bool component of the returned pair is true if and only if the insertion
-takes place...
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="317"></a>317. Instantiation vs. specialization of facets</h3>
-<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-04</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The localization section of the standard refers to specializations of
-the facet templates as instantiations even though the required facets
-are typically specialized rather than explicitly (or implicitly)
-instantiated. In the case of ctype&lt;char&gt; and
-ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
-actually required to be specialized. The terminology should be
-corrected to make it clear that the standard doesn't mandate explicit
-instantiation (the term specialization encompasses both explicit
-instantiations and specializations).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In the following paragraphs, replace all occurrences of the word
-instantiation or instantiations with specialization or specializations,
-respectively:
-</p>
-
-<blockquote><p>
-22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
-22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
-22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
-Footnote 242.
-</p></blockquote>
-
-<p>And change the text in 22.1.1.1.1, p4 from</p>
-
-<blockquote><p>
- An implementation is required to provide those instantiations
- for facet templates identified as members of a category, and
- for those shown in Table 52:
-</p></blockquote>
-
-<p>to</p>
-
-<blockquote><p>
- An implementation is required to provide those specializations...
-</p></blockquote>
-
-<p><i>[Nathan will review these changes, and will look for places where
-explicit specialization is necessary.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>This is a simple matter of outdated language. The language to
-describe templates was clarified during the standardization process,
-but the wording in clause 22 was never updated to reflect that
-change.</p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="318"></a>318. Misleading comment in definition of numpunct_byname</h3>
-<p><b>Section:</b> 22.2.3.2 [locale.numpunct.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-05-12</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The definition of the numpunct_byname template contains the following
-comment:</p>
-
-<pre> namespace std {
- template &lt;class charT&gt;
- class numpunct_byname : public numpunct&lt;charT&gt; {
- // this class is specialized for char and wchar_t.
- ...
-</pre>
-
-<p>There is no documentation of the specializations and it seems
-conceivable that an implementation will not explicitly specialize the
-template at all, but simply provide the primary template.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Remove the comment from the text in 22.2.3.2 and from the proposed
-resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
-
-
-
-
-<hr>
-<h3><a name="319"></a>319. Storage allocation wording confuses "Required behavior", "Requires"</h3>
-<p><b>Section:</b> 18.5.1.1 [new.delete.single], 18.5.1.2 [new.delete.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2001-05-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#new.delete.single">issues</a> in [new.delete.single].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The standard specifies 17.3.1.3 [structure.specifications] that "Required
-behavior" elements describe "the semantics of a function definition
-provided by either the implementation or a C++ program."</p>
-
-<p>The standard specifies 17.3.1.3 [structure.specifications] that "Requires"
-elements describe "the preconditions for calling the function."</p>
-
-<p>In the sections noted below, the current wording specifies
-"Required Behavior" for what are actually preconditions, and thus
-should be specified as "Requires".</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>In 18.5.1.1 [new.delete.single] Para 12 Change:</p>
-<blockquote>
- <p>Required behavior: accept a value of ptr that is null or that was
- returned by an earlier call ...</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>Requires: the value of ptr is null or the value returned by an
- earlier call ...</p>
-</blockquote>
-
-<p>In 18.5.1.2 [new.delete.array] Para 11 Change:</p>
-<blockquote>
- <p>Required behavior: accept a value of ptr that is null or that was
- returned by an earlier call ...</p>
-</blockquote>
-<p>to:</p>
-<blockquote>
- <p>Requires: the value of ptr is null or the value returned by an
- earlier call ...</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="320"></a>320. list::assign overspecified</h3>
-<p><b>Section:</b> 23.2.4.1 [list.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2001-05-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 23.2.4.1 [list.cons], paragraphs 6-8 specify that list assign (both forms) have
-the "effects" of a call to erase followed by a call to insert.
-</p>
-
-<p>
-I would like to document that implementers have the freedom to implement
-assign by other methods, as long as the end result is the same and the
-exception guarantee is as good or better than the basic guarantee.
-</p>
-
-<p>
-The motivation for this is to use T's assignment operator to recycle
-existing nodes in the list instead of erasing them and reallocating
-them with new values. It is also worth noting that, with careful
-coding, most common cases of assign (everything but assignment with
-true input iterators) can elevate the exception safety to strong if
-T's assignment has a nothrow guarantee (with no extra memory cost).
-Metrowerks does this. However I do not propose that this subtlety be
-standardized. It is a QoI issue. </p>
-
-<p>Existing practise:
-Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 23.2.4.1 [list.cons]/7 from:</p>
-
-<blockquote>
-<p>Effects:</p>
-
-<pre> erase(begin(), end());
- insert(begin(), first, last);
-</pre>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-<p>Effects: Replaces the contents of the list with the range [first, last).</p>
-</blockquote>
-
-<p>In 23.1.3 [sequence.reqmts], in Table 67 (sequence requirements),
-add two new rows:</p>
-<pre> a.assign(i,j) void pre: i,j are not iterators into a.
- Replaces elements in a with a copy
- of [i, j).
-
- a.assign(n,t) void pre: t is not a reference into a.
- Replaces elements in a with n copies
- of t.
-</pre>
-
-<p>Change 23.2.4.1 [list.cons]/8 from:</p>
-
-<blockquote>
-<p>Effects:</p>
-<pre> erase(begin(), end());
- insert(begin(), n, t);
-</pre>
-</blockquote>
-<p>to:</p>
-
-<blockquote>
-<p>Effects: Replaces the contents of the list with n copies of t.</p>
-</blockquote>
-
-<p><i>[Redmond: Proposed resolution was changed slightly. Previous
-version made explicit statement about exception safety, which wasn't
-consistent with the way exception safety is expressed elsewhere.
-Also, the change in the sequence requirements is new. Without that
-change, the proposed resolution would have required that assignment of
-a subrange would have to work. That too would have been
-overspecification; it would effectively mandate that assignment use a
-temporary. Howard provided wording.
-]</i></p>
-
-
-<p><i>[Curaao: Made editorial improvement in wording; changed
-"Replaces elements in a with copies of elements in [i, j)."
-with "Replaces the elements of a with a copy of [i, j)."
-Changes not deemed serious enough to requre rereview.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="321"></a>321. Typo in num_get</h3>
-<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Kevin Djang <b>Date:</b> 2001-05-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 22.2.2.1.2 at p7 states that "A length specifier is added to
-the conversion function, if needed, as indicated in Table 56."
-However, Table 56 uses the term "length modifier", not "length
-specifier".
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
-to be "A length modifier is added ..."
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>C uses the term "length modifier". We should be consistent.</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="322"></a>322. iterator and const_iterator should have the same value type</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2001-05-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It's widely assumed that, if X is a container,
-iterator_traits&lt;X::iterator&gt;::value_type and
-iterator_traits&lt;X::const_iterator&gt;::value_type should both be
-X::value_type. However, this is nowhere stated. The language in
-Table 65 is not precise about the iterators' value types (it predates
-iterator_traits), and could even be interpreted as saying that
-iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
-X::value_type".
-</p>
-
-<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In Table 65 ("Container Requirements"), change the return type for
-X::iterator to "iterator type whose value type is T". Change the
-return type for X::const_iterator to "constant iterator type whose
-value type is T".</p>
-
-
-<p><b>Rationale:</b></p>
-<p>
-This belongs as a container requirement, rather than an iterator
-requirement, because the whole notion of iterator/const_iterator
-pairs is specific to containers' iterator.
-</p>
-<p>
-It is existing practice that (for example)
-iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
-is "int", rather than "const int". This is consistent with
-the way that const pointers are handled: the standard already
-requires that iterator_traits&lt;const int*&gt;::value_type is int.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="324"></a>324. Do output iterators have value types?</h3>
-<p><b>Section:</b> 24.1.2 [output.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2001-06-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#output.iterators">issues</a> in [output.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>Table 73 suggests that output iterators have value types. It
-requires the expression "*a = t". Additionally, although Table 73
-never lists "a = t" or "X(a) = t" in the "expressions" column, it
-contains a note saying that "a = t" and "X(a) = t" have equivalent
-(but nowhere specified!) semantics.</p>
-
-<p>According to 24.1/9, t is supposed to be "a value of value type
-T":</p>
-
- <blockquote><p>
- In the following sections, a and b denote values of X, n denotes a
- value of the difference type Distance, u, tmp, and m denote
- identifiers, r denotes a value of X&amp;, t denotes a value of
- value type T.
- </p></blockquote>
-
-<p>Two other parts of the standard that are relevant to whether
-output iterators have value types:</p>
-
-<ul>
- <li>24.1/1 says "All iterators i support the expression *i,
- resulting in a value of some class, enumeration, or built-in type
- T, called the value type of the iterator".</li>
-
- <li>
- 24.3.1/1, which says "In the case of an output iterator, the types
- iterator_traits&lt;Iterator&gt;::difference_type
- iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
- </li>
-</ul>
-
-<p>The first of these passages suggests that "*i" is supposed to
-return a useful value, which contradicts the note in 24.1.2/2 saying
-that the only valid use of "*i" for output iterators is in an
-expression of the form "*i = t". The second of these passages appears
-to contradict Table 73, because it suggests that "*i"'s return value
-should be void. The second passage is also broken in the case of a an
-iterator type, like non-const pointers, that satisfies both the output
-iterator requirements and the forward iterator requirements.</p>
-
-<p>What should the standard say about <tt>*i</tt>'s return value when
-i is an output iterator, and what should it say about that t is in the
-expression "*i = t"? Finally, should the standard say anything about
-output iterators' pointer and reference types?</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>24.1 p1, change</p>
-
-<blockquote>
-<p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
-in a value of some class, enumeration, or built-in type <tt>T</tt>,
-called the value type of the iterator.</p>
-</blockquote>
-
-<p>to</p>
-
-<blockquote>
-<p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
-resulting in a value of some class, enumeration, or built-in type
-<tt>T</tt>, called the value type of the iterator. All output
-iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
-value of some type that is in the set of types that are <i>writable</i> to
-the particular iterator type of <tt>i</tt>.
-</p>
-</blockquote>
-
-<p>24.1 p9, add</p>
-
-<blockquote>
-<p><tt>o</tt> denotes a value of some type that is writable to the
-output iterator.
-</p>
-</blockquote>
-
-<p>Table 73, change</p>
-
-<blockquote>
-<pre>*a = t
-</pre>
-</blockquote>
-
-<p>to</p>
-
-<blockquote>
-<pre>*r = o
-</pre>
-</blockquote>
-
-<p>and change</p>
-
-<blockquote>
-<pre>*r++ = t
-</pre>
-</blockquote>
-
-<p>to</p>
-
-<blockquote>
-<pre>*r++ = o
-</pre>
-</blockquote>
-
-<p><i>[post-Redmond: Jeremy provided wording]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG considered two options: change all of the language that
-seems to imply that output iterators have value types, thus making it
-clear that output iterators have no value types, or else define value
-types for output iterator consistently. The LWG chose the former
-option, because it seems clear that output iterators were never
-intended to have value types. This was a deliberate design decision,
-and any language suggesting otherwise is simply a mistake.</p>
-
-<p>A future revision of the standard may wish to revisit this design
-decision.</p>
-
-
-
-
-
-<hr>
-<h3><a name="325"></a>325. Misleading text in moneypunct&lt;&gt;::do_grouping</h3>
-<p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The Returns clause in 22.2.6.3.2, p3 says about
-moneypunct&lt;charT&gt;::do_grouping()
-</p>
-
-<blockquote><p>
- Returns: A pattern defined identically as the result of
- numpunct&lt;charT&gt;::do_grouping().241)
-</p></blockquote>
-
-<p>Footnote 241 then reads</p>
-
-<blockquote><p>
- This is most commonly the value "\003" (not "3").
-</p></blockquote>
-
-<p>
-The returns clause seems to imply that the two member functions must
-return an identical value which in reality may or may not be true,
-since the facets are usually implemented in terms of struct std::lconv
-and return the value of the grouping and mon_grouping, respectively.
-The footnote also implies that the member function of the moneypunct
-facet (rather than the overridden virtual functions in moneypunct_byname)
-most commonly return "\003", which contradicts the C standard which
-specifies the value of "" for the (most common) C locale.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
-
-<blockquote><p>
- Returns: A pattern defined identically as, but not necessarily
- equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
-</p></blockquote>
-
-<p>and replace the text in Footnote 241 with the following:</p>
-
-<blockquote><p>
- To specify grouping by 3s the value is "\003", not "3".
-</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>
-The fundamental problem is that the description of the locale facet
-virtuals serves two purposes: describing the behavior of the base
-class, and describing the meaning of and constraints on the behavior
-in arbitrary derived classes. The new wording makes that separation a
-little bit clearer. The footnote (which is nonnormative) is not
-supposed to say what the grouping is in the "C" locale or in any other
-locale. It is just a reminder that the values are interpreted as small
-integers, not ASCII characters.
-</p>
-
-
-
-
-<hr>
-<h3><a name="327"></a>327. Typo in time_get facet in table 52</h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Tiki Wan <b>Date:</b> 2001-07-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#447">447</a></p>
-<p><b>Discussion:</b></p>
-<p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
-<tt>time_get_byname</tt> are listed incorrectly in table 52,
-required instantiations. In both cases the second template
-parameter is given as OutputIterator. It should instead be
-InputIterator, since these are input facets.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In table 52, required instantiations, in
-22.1.1.1.1 [locale.category], change</p>
-<pre> time_get&lt;wchar_t, OutputIterator&gt;
- time_get_byname&lt;wchar_t, OutputIterator&gt;
-</pre>
-<p>to</p>
-<pre> time_get&lt;wchar_t, InputIterator&gt;
- time_get_byname&lt;wchar_t, InputIterator&gt;
-</pre>
-
-<p><i>[Redmond: Very minor change in proposed resolution. Original had
-a typo, wchart instead of wchar_t.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="328"></a>328. Bad sprintf format modifier in money_put&lt;&gt;::do_put()</h3>
-<p><b>Section:</b> 22.2.6.2.2 [locale.money.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-07-07</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The sprintf format string , "%.01f" (that's the digit one), in the
-description of the do_put() member functions of the money_put facet in
-22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
-for values of type long double, and second, the precision of 01
-doesn't seem to make sense. What was most likely intended was
-"%.0Lf"., that is a precision of zero followed by the L length
-modifier.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the format string to "%.0Lf".</p>
-
-
-<p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
-
-
-
-
-<hr>
-<h3><a name="329"></a>329. vector capacity, reserve and reallocation</h3>
-<p><b>Section:</b> 23.2.6.2 [vector.capacity], 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-07-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There is an apparent contradiction about which circumstances can cause
-a reallocation of a vector in Section 23.2.6.2 [vector.capacity] and
-section 23.2.6.4 [vector.modifiers].
-</p>
-
-<p>23.2.6.2 [vector.capacity],p5 says:</p>
-<blockquote><p>
-Notes: Reallocation invalidates all the references, pointers, and iterators
-referring to the elements in the sequence. It is guaranteed that no
-reallocation takes place during insertions that happen after a call to
-reserve() until the time when an insertion would make the size of the vector
-greater than the size specified in the most recent call to reserve().
-</p></blockquote>
-
-<p>Which implies if I do</p>
-
-<pre> std::vector&lt;int&gt; vec;
- vec.reserve(23);
- vec.reserve(0);
- vec.insert(vec.end(),1);
-</pre>
-
-<p>then the implementation may reallocate the vector for the insert,
-as the size specified in the previous call to reserve was zero.</p>
-
-<p>However, the previous paragraphs (23.2.6.2 [vector.capacity], p1-2) state:</p>
-<blockquote>
-<p>
-(capacity) Returns: The total number of elements the vector
-can hold without requiring reallocation
-</p>
-<p>
-...After reserve(), capacity() is greater or equal to the
-argument of reserve if reallocation happens; and equal to the previous value
-of capacity() otherwise...
-</p>
-</blockquote>
-
-<p>
-This implies that vec.capacity() is still 23, and so the insert()
-should not require a reallocation, as vec.size() is 0. This is backed
-up by 23.2.6.4 [vector.modifiers], p1:
-</p>
-<blockquote><p>
-(insert) Notes: Causes reallocation if the new size is greater than the old
-capacity.
-</p></blockquote>
-
-<p>
-Though this doesn't rule out reallocation if the new size is less
-than the old capacity, I think the intent is clear.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the wording of 23.2.6.2 [vector.capacity] paragraph 5 to:</p>
-
-<blockquote><p>
-Notes: Reallocation invalidates all the references, pointers, and
-iterators referring to the elements in the sequence. It is guaranteed
-that no reallocation takes place during insertions that happen after a
-call to reserve() until the time when an insertion would make the size
-of the vector greater than the value of capacity().
-</p></blockquote>
-
-<p><i>[Redmond: original proposed resolution was modified slightly. In
-the original, the guarantee was that there would be no reallocation
-until the size would be greater than the value of capacity() after the
-most recent call to reserve(). The LWG did not believe that the
-"after the most recent call to reserve()" added any useful
-information.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>There was general agreement that, when reserve() is called twice in
-succession and the argument to the second invocation is smaller than
-the argument to the first, the intent was for the second invocation to
-have no effect. Wording implying that such cases have an effect on
-reallocation guarantees was inadvertant.</p>
-
-
-
-
-
-<hr>
-<h3><a name="331"></a>331. bad declaration of destructor for ios_base::failure</h3>
-<p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-With the change in 17.4.4.9 [res.on.exception.handling] to state
- "An implementation may strengthen the exception-specification for a
- non-virtual function by removing listed exceptions."
-(issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
-and the following declaration of ~failure() in ios_base::failure
-</p>
-<pre> namespace std {
- class ios_base::failure : public exception {
- public:
- ...
- virtual ~failure();
- ...
- };
- }
-</pre>
-<p>the class failure cannot be implemented since in 18.6.1 [type.info] the destructor of class exception has an empty
-exception specification:</p>
-<pre> namespace std {
- class exception {
- public:
- ...
- virtual ~exception() throw();
- ...
- };
- }
-</pre>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Remove the declaration of ~failure().</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The proposed resolution is consistent with the way that destructors
-of other classes derived from <tt>exception</tt> are handled.</p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="333"></a>333. does endl imply synchronization with the device?</h3>
-<p><b>Section:</b> 27.6.2.8 [ostream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 2001-08-27</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>A footnote in 27.6.2.8 [ostream.manip] states:</p>
-<blockquote><p>
- [Footnote: The effect of executing cout &lt;&lt; endl is to insert a
- newline character in the output sequence controlled by cout, then
- synchronize it with any external file with which it might be
- associated. --- end foonote]
-</p></blockquote>
-
-<p>
-Does the term "file" here refer to the external device?
-This leads to some implementation ambiguity on systems with fully
-buffered files where a newline does not cause a flush to the device.
-</p>
-
-<p>
-Choosing to sync with the device leads to significant performance
-penalties for each call to endl, while not sync-ing leads to
-errors under special circumstances.
-</p>
-
-<p>
-I could not find any other statement that explicitly defined
-the behavior one way or the other.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Remove footnote 300 from section 27.6.2.8 [ostream.manip].</p>
-
-
-<p><b>Rationale:</b></p>
-<p>We already have normative text saying what <tt>endl</tt> does: it
-inserts a newline character and calls <tt>flush</tt>. This footnote
-is at best redundant, at worst (as this issue says) misleading,
-because it appears to make promises about what <tt>flush</tt>
-does.</p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="334"></a>334. map::operator[] specification forces inefficient implementation</h3>
-<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andrea Griffini <b>Date:</b> 2001-09-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The current standard describes map::operator[] using a
-code example. That code example is however quite
-inefficient because it requires several useless copies
-of both the passed key_type value and of default
-constructed mapped_type instances.
-My opinion is that was not meant by the comitee to
-require all those temporary copies.
-</p>
-
-<p>Currently map::operator[] behaviour is specified as: </p>
-<pre> Returns:
- (*((insert(make_pair(x, T()))).first)).second.
-</pre>
-
-<p>
-This specification however uses make_pair that is a
-template function of which parameters in this case
-will be deduced being of type const key_type&amp; and
-const T&amp;. This will create a pair&lt;key_type,T&gt; that
-isn't the correct type expected by map::insert so
-another copy will be required using the template
-conversion constructor available in pair to build
-the required pair&lt;const key_type,T&gt; instance.
-</p>
-
-<p>If we consider calling of key_type copy constructor
-and mapped_type default constructor and copy
-constructor as observable behaviour (as I think we
-should) then the standard is in this place requiring
-two copies of a key_type element plus a default
-construction and two copy construction of a mapped_type
-(supposing the addressed element is already present
-in the map; otherwise at least another copy
-construction for each type).
-</p>
-
-<p>A simple (half) solution would be replacing the description with:</p>
-<pre> Returns:
- (*((insert(value_type(x, T()))).first)).second.
-</pre>
-
-<p>This will remove the wrong typed pair construction that
-requires one extra copy of both key and value.</p>
-
-<p>However still the using of map::insert requires temporary
-objects while the operation, from a logical point of view,
-doesn't require any. </p>
-
-<p>I think that a better solution would be leaving free an
-implementer to use a different approach than map::insert
-that, because of its interface, forces default constructed
-temporaries and copies in this case.
-The best solution in my opinion would be just requiring
-map::operator[] to return a reference to the mapped_type
-part of the contained element creating a default element
-with the specified key if no such an element is already
-present in the container. Also a logarithmic complexity
-requirement should be specified for the operation.
-</p>
-
-<p>
-This would allow library implementers to write alternative
-implementations not using map::insert and reaching optimal
-performance in both cases of the addressed element being
-present or absent from the map (no temporaries at all and
-just the creation of a new pair inside the container if
-the element isn't present).
-Some implementer has already taken this option but I think
-that the current wording of the standard rules that as
-non-conforming.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Replace 23.3.1.2 [map.access] paragraph 1 with
-</p>
-<blockquote>
-<p>
--1- Effects: If there is no key equivalent to x in the map, inserts
-value_type(x, T()) into the map.
-</p>
-<p>
--2- Returns: A reference to the mapped_type corresponding to x in *this.
-</p>
-<p>
--3- Complexity: logarithmic.
-</p>
-</blockquote>
-
-<p><i>[This is the second option mentioned above. Howard provided
-wording. We may also wish to have a blanket statement somewhere in
-clause 17 saying that we do not intend the semantics of sample code
-fragments to be interpreted as specifing exactly how many copies are
-made. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a> for a similar problem.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-This is the second solution described above; as noted, it is
-consistent with existing practice.
-</p>
-
-<p>Note that we now need to specify the complexity explicitly, because
-we are no longer defining <tt>operator[]</tt> in terms of
-<tt>insert</tt>.</p>
-
-
-
-
-
-<hr>
-<h3><a name="335"></a>335. minor issue with char_traits, table 37</h3>
-<p><b>Section:</b> 21.1.1 [char.traits.require] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-09-06</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Table 37, in 21.1.1 [char.traits.require], descibes char_traits::assign
-as:
-</p>
-<pre> X::assign(c,d) assigns c = d.
-</pre>
-
-<p>And para 1 says:</p>
-
-<blockquote><p>
- [...] c and d denote values of type CharT [...]
-</p></blockquote>
-
-<p>
-Naturally, if c and d are <i>values</i>, then the assignment is
-(effectively) meaningless. It's clearly intended that (in the case of
-assign, at least), 'c' is intended to be a reference type.
-</p>
-
-<p>I did a quick survey of the four implementations I happened to have
-lying around, and sure enough they all have signatures:</p>
-<pre> assign( charT&amp;, const charT&amp; );
-</pre>
-
-<p>(or the equivalent). It's also described this way in Nico's book.
-(Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
-and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add the following to 21.1.1 para 1:</p>
-<blockquote><p>
- r denotes an lvalue of CharT
-</p></blockquote>
-
-<p>and change the description of assign in the table to:</p>
-<pre> X::assign(r,d) assigns r = d
-</pre>
-
-
-
-
-
-<hr>
-<h3><a name="336"></a>336. Clause 17 lack of references to deprecated headers</h3>
-<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-09-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#library">issues</a> in [library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>From c++std-edit-873:</p>
-
-<p>17.4.1.2 [headers], Table 11. In this table, the header
-&lt;strstream&gt; is missing.</p>
-
-<p>This shows a general problem: The whole clause 17 refers quite
-often to clauses 18 through 27, but D.7 is also a part of the standard
-library (though a deprecated one).</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>To 17.4.1.2 [headers] Table 11, C++ Library Headers, add
-"&lt;strstream&gt;".</p>
-
-<p>In the following places, change "clauses 17 through 27" to "clauses
-17 through 27 and Annex D":</p>
-
-<ul>
-<li>1.2 [intro.refs] Normative references/1/footnote 1</li>
-<li>1.3 [intro.defs] Definitions/1</li>
-<li>7 [dcl.dcl] Library introduction/9</li>
-<li>17.3 [description] Method of description (Informative)/1</li>
-<li>17.3.2.1.3 [character.seq] Character sequences/1/bullet 2</li>
-<li>17.3.2.2 [functions.within.classes] Functions within classes/1</li>
-<li>17.3.2.3 [objects.within.classes] Private members/1/(2 places)</li>
-<li>17.4 [requirements] Library-wide requirements/1</li>
-<li>17.4.1.2 [headers] Headers/4</li>
-<li>17.4.3.5 [replacement.functions] Replacement functions/1</li>
-<li>17.4.4.3 [global.functions] Global or non-member functions/2</li>
-<li>17.4.4.7 [protection.within.classes] Protection within classes/1</li>
-</ul>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="337"></a>337. replace_copy_if's template parameter should be InputIterator</h3>
-<p><b>Section:</b> 25.2.5 [alg.replace] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 2001-09-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.replace">issues</a> in [alg.replace].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>From c++std-edit-876:</p>
-
-<p>
-In section 25.2.5 [alg.replace] before p4: The name of the first
-parameter of template replace_copy_if should be "InputIterator"
-instead of "Iterator". According to 17.3.2.1 [type.descriptions] p1 the
-parameter name conveys real normative meaning.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
-
-
-
-
-
-<hr>
-<h3><a name="338"></a>338. is whitespace allowed between `-' and a digit?</h3>
-<p><b>Section:</b> 22.2 [locale.categories] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-17</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#locale.categories">active issues</a> in [locale.categories].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.categories">issues</a> in [locale.categories].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-From Stage 2 processing in 22.2.2.1.2 [facet.num.get.virtuals], p8 and 9 (the
-original text or the text corrected by the proposed resolution of
-issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
-within a number, but 22.2.3.1 [locale.numpunct], p2, which gives the
-format for integer and floating point values, says that whitespace is
-optional between a plusminus and a sign.
-</p>
-
-<p>
-The text needs to be clarified to either consistently allow or
-disallow whitespace between a plusminus and a sign. It might be
-worthwhile to consider the fact that the C library stdio facility does
-not permit whitespace embedded in numbers and neither does the C or
-C++ core language (the syntax of integer-literals is given in 2.13.1
-[lex.icon], that of floating-point-literals in 2.13.3 [lex.fcon] of the
-C++ standard).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the first part of 22.2.3.1 [locale.numpunct] paragraph 2 from:</p>
-<blockquote>
-<p>
-The syntax for number formats is as follows, where <tt>digit</tt>
-represents the radix set specified by the <tt>fmtflags</tt> argument
-value, <tt>whitespace</tt> is as determined by the facet
-<tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
-<tt>decimal-point</tt> are the results of corresponding
-<tt>numpunct&lt;charT&gt;</tt> members. Integer values have the
-format:
-</p>
-<pre> integer ::= [sign] units
- sign ::= plusminus [whitespace]
- plusminus ::= '+' | '-'
- units ::= digits [thousands-sep units]
- digits ::= digit [digits]
-</pre>
-</blockquote>
-<p>to:</p>
-<blockquote>
-<p>
-The syntax for number formats is as follows, where <tt>digit</tt>
-represents the radix set specified by the <tt>fmtflags</tt> argument
-value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
-results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
-Integer values have the format:
-</p>
-<pre> integer ::= [sign] units
- sign ::= plusminus
- plusminus ::= '+' | '-'
- units ::= digits [thousands-sep units]
- digits ::= digit [digits]
-</pre>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>It's not clear whether the format described in 22.2.3.1 [locale.numpunct] paragraph 2 has any normative weight: nothing in the
-standard says how, or whether, it's used. However, there's no reason
-for it to differ gratuitously from the very specific description of
-numeric processing in 22.2.2.1.2 [facet.num.get.virtuals]. The proposed
-resolution removes all mention of "whitespace" from that format.</p>
-
-
-
-
-
-<hr>
-<h3><a name="339"></a>339. definition of bitmask type restricted to clause 27</h3>
-<p><b>Section:</b> 22.2.1 [category.ctype], 17.3.2.1.2 [bitmask.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#category.ctype">issues</a> in [category.ctype].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>The ctype_category::mask type is declared to be an enum in 22.2.1
-[category.ctype] with p1 then stating that it is a bitmask type, most
-likely referring to the definition of bitmask type in 17.3.2.1.2
-[bitmask.types], p1. However, the said definition only applies to
-clause 27, making the reference in 22.2.1 somewhat dubious.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
- <blockquote><p>
- Several types defined in clause 27 are bitmask types. Each bitmask type
- can be implemented as an enumerated type that overloads certain operators,
- as an integer type, or as a bitset (23.3.5 [template.bitset]).
- </p></blockquote>
-<p>to read</p>
- <blockquote><p>
- Several types defined in clauses lib.language.support through
- lib.input.output and Annex D are bitmask types. Each bitmask type can
- be implemented as an enumerated type that overloads certain operators,
- as an integer type, or as a bitset (lib.template.bitset).
- </p></blockquote>
-
-<p>
-Additionally, change the definition in 22.2.1 to adopt the same
-convention as in clause 27 by replacing the existing text with the
-following (note, in particluar, the cross-reference to 17.3.2.1.2 in
-22.2.1, p1):
-</p>
-
-<blockquote>
-<p>22.2.1 The ctype category [lib.category.ctype]</p>
-<pre>namespace std {
- class ctype_base {
- public:
- typedef <b><i>T</i></b> mask;
-
- // numeric values are for exposition only.
- static const mask space = 1 &lt;&lt; 0;
- static const mask print = 1 &lt;&lt; 1;
- static const mask cntrl = 1 &lt;&lt; 2;
- static const mask upper = 1 &lt;&lt; 3;
- static const mask lower = 1 &lt;&lt; 4;
- static const mask alpha = 1 &lt;&lt; 5;
- static const mask digit = 1 &lt;&lt; 6;
- static const mask punct = 1 &lt;&lt; 7;
- static const mask xdigit = 1 &lt;&lt; 8;
- static const mask alnum = alpha | digit;
- static const mask graph = alnum | punct;
- };
-}
-</pre>
-
-<p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 [bitmask.types]).</p>
-</blockquote>
-
-<p><i>[Curaao: The LWG notes that T above should be bold-italics to be
-consistent with the rest of the standard.]</i></p>
-
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="340"></a>340. interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt></h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-09-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It's unclear whether 22.1.1.1.1, p3 says that
-<tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
-from Table 51 or whether it includes Table 52 as well:
-</p>
-
-<blockquote><p>
-For any locale <tt>loc</tt> either constructed, or returned by
-locale::classic(), and any facet <tt>Facet</tt> that is a member of a
-standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
-locale member function which takes a <tt>locale::category</tt>
-argument operates on the corresponding set of facets.
-</p></blockquote>
-
-<p>
-It seems that it comes down to which facets are considered to be members of a
-standard category. Intuitively, I would classify all the facets in Table 52 as
-members of their respective standard categories, but there are an unbounded set
-of them...
-</p>
-
-<p>
-The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
-OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
-possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
-&gt;(loc)</tt> would have to return a reference to a distinct object for each
-valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
-clearly impossible.
-</p>
-
-<p>
-On the other hand, if none of the facets in Table 52 is a member of a standard
-category then none of the locale member functions that operate on entire
-categories of facets will work properly.
-</p>
-
-<p>
-It seems that what p3 should mention that it's required (permitted?)
-to hold only for specializations of <tt>Facet</tt> from Table 52 on
-<tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
-<tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
-{
-{i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
-}.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.1.1.1.1 [locale.category], paragraph 3, change
-"that is a member of a standard category" to "shown in Table 51".</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The facets in Table 52 are an unbounded set. Locales should not be
-required to contain an infinite number of facets.</p>
-
-<p>It's not necessary to talk about which values of InputIterator and
-OutputIterator must be supported. Table 51 already contains a
-complete list of the ones we need.</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="341"></a>341. Vector reallocation and swap</h3>
-<p><b>Section:</b> 23.2.6.2 [vector.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Anthony Williams <b>Date:</b> 2001-09-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>It is a common idiom to reduce the capacity of a vector by swapping it with
-an empty one:</p>
-<pre> std::vector&lt;SomeType&gt; vec;
- // fill vec with data
- std::vector&lt;SomeType&gt;().swap(vec);
- // vec is now empty, with minimal capacity
-</pre>
-
-<p>However, the wording of 23.2.6.2 [vector.capacity]paragraph 5 prevents
-the capacity of a vector being reduced, following a call to
-reserve(). This invalidates the idiom, as swap() is thus prevented
-from reducing the capacity. The proposed wording for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a> does not affect this. Consequently, the example above
-requires the temporary to be expanded to cater for the contents of
-vec, and the contents be copied across. This is a linear-time
-operation.</p>
-
-<p>However, the container requirements state that swap must have constant
-complexity (23.1 [container.requirements] note to table 65).</p>
-
-<p>This is an important issue, as reallocation affects the validity of
-references and iterators.</p>
-
-<p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
-references and iterators remain valid after a call to swap, if they refer to
-an element before the new end() of the vector into which they originally
-pointed, in which case they refer to the element at the same index position.
-Iterators and references that referred to an element whose index position
-was beyond the new end of the vector are invalidated.</p>
-
-<p>If the note to table 65 is taken as the desired intent, then there are two
-possibilities with regard to iterators and references:</p>
-
-<ol>
-<li>All Iterators and references into both vectors are invalidated.</li>
-<li>Iterators and references into either vector remain valid, and remain
-pointing to the same element. Consequently iterators and references that
-referred to one vector now refer to the other, and vice-versa.</li>
-</ol>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add a new paragraph after 23.2.6.2 [vector.capacity] paragraph 5:</p>
-<blockquote>
-<pre> void swap(vector&lt;T,Allocator&gt;&amp; x);
-</pre>
-<p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
-with that of <tt>x</tt>.</p>
-<p><b>Complexity:</b> Constant time.</p>
-</blockquote>
-
-<p><i>[This solves the problem reported for this issue. We may also
-have a problem with a circular definition of swap() for other
-containers.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-swap should be constant time. The clear intent is that it should just
-do pointer twiddling, and that it should exchange all properties of
-the two vectors, including their reallocation guarantees.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="345"></a>345. type tm in &lt;cwchar&gt;</h3>
-<p><b>Section:</b> 21.5 [c.strings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Clark Nelson <b>Date:</b> 2001-10-19</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.strings">issues</a> in [c.strings].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
-declares struct tm as an incomplete type. However, table 48 in 21.5
-[c.strings] does not mention the type tm as being declared in
-&lt;cwchar&gt;. Is this omission intentional or accidental?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In section 21.5 [c.strings], add "tm" to table 48.</p>
-
-
-
-
-
-<hr>
-<h3><a name="346"></a>346. Some iterator member functions should be const</h3>
-<p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Jeremy Siek <b>Date:</b> 2001-10-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Iterator member functions and operators that do not change the state
-of the iterator should be defined as const member functions or as
-functions that take iterators either by const reference or by
-value. The standard does not explicitly state which functions should
-be const. Since this a fairly common mistake, the following changes
-are suggested to make this explicit.</p>
-
-<p>The tables almost indicate constness properly through naming: r
-for non-const and a,b for const iterators. The following changes
-make this more explicit and also fix a couple problems.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 24.1 [iterator.requirements] Change the first section of p9 from
-"In the following sections, a and b denote values of X..." to
-"In the following sections, a and b denote values of type const X...".</p>
-
-<p>In Table 73, change</p>
-<pre> a-&gt;m U&amp; ...
-</pre>
-
-<p>to</p>
-
-<pre> a-&gt;m const U&amp; ...
- r-&gt;m U&amp; ...
-</pre>
-
-<p>In Table 73 expression column, change</p>
-
-<pre> *a = t
-</pre>
-
-<p>to</p>
-
-<pre> *r = t
-</pre>
-
-<p><i>[Redmond: The container requirements should be reviewed to see if
-the same problem appears there.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="347"></a>347. locale::category and bitmask requirements</h3>
-<p><b>Section:</b> 22.1.1.1.1 [locale.category] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> P.J. Plauger, Nathan Myers <b>Date:</b> 2001-10-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.category">issues</a> in [locale.category].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 22.1.1.1.1 [locale.category] paragraph 1, the category members
-are described as bitmask elements. In fact, the bitmask requirements
-in 17.3.2.1.2 [bitmask.types] don't seem quite right: <tt>none</tt>
-and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
-
-<p>In particular, the requirements for <tt>none</tt> interact poorly
-with the requirement that the LC_* constants from the C library must
-be recognizable as C++ locale category constants. LC_* values should
-not be mixed with these values to make category values.</p>
-
-<p>We have two options for the proposed resolution. Informally:
-option 1 removes the requirement that LC_* values be recognized as
-category arguments. Option 2 changes the category type so that this
-requirement is implementable, by allowing <tt>none</tt> to be some
-value such as 0x1000 instead of 0.</p>
-
-<p>Nathan writes: "I believe my proposed resolution [Option 2] merely
-re-expresses the status quo more clearly, without introducing any
-changes beyond resolving the DR.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace the first two paragraphs of 22.1.1.1 [locale.types] with:</p>
-<blockquote>
-<pre> typedef int category;
-</pre>
-
-<p>Valid category values include the <tt>locale</tt> member bitmask
-elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
-<tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
-represents a single locale category. In addition, <tt>locale</tt> member
-bitmask constant <tt>none</tt> is defined as zero and represents no
-category. And locale member bitmask constant <tt>all</tt> is defined such that
-the expression</p>
-<pre> (collate | ctype | monetary | numeric | time | messages | all) == all
-</pre>
-<p>
-is <tt>true</tt>, and represents the union of all categories. Further
-the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
-represent a single category, represents the union of the two
-categories.
-</p>
-
-<p>
-<tt>locale</tt> member functions expecting a <tt>category</tt>
-argument require one of the <tt>category</tt> values defined above, or
-the union of two or more such values. Such a <tt>category</tt>
-argument identifies a set of locale categories. Each locale category,
-in turn, identifies a set of locale facets, including at least those
-shown in Table 51:
-</p>
-</blockquote>
-<p><i>[Curaao: need input from locale experts.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-
-<p>The LWG considered, and rejected, an alternate proposal (described
- as "Option 2" in the discussion). The main reason for rejecting it
- was that library implementors were concerened about implementation
- difficult, given that getting a C++ library to work smoothly with a
- separately written C library is already a delicate business. Some
- library implementers were also concerned about the issue of adding
- extra locale categories.</p>
-
-<blockquote>
-<p><b>Option 2:</b> <br>
-Replace the first paragraph of 22.1.1.1 [locale.types] with:</p>
-<blockquote>
-<p>
-Valid category values include the enumerated values. In addition, the
-result of applying commutative operators | and &amp; to any two valid
-values is valid, and results in the setwise union and intersection,
-respectively, of the argument categories. The values <tt>all</tt> and
-<tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
-expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
-<tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are
-true. For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
-remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
-For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
-of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of
-those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
-[Footnote: it is not required that <tt>all</tt> equal the setwise union
-of the other enumerated values; implementations may add extra categories.]
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="349"></a>349. Minor typographical error in ostream_iterator</h3>
-<p><b>Section:</b> 24.5.2 [ostream.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andy Sawyer <b>Date:</b> 2001-10-24</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>24.5.2 [lib.ostream.iterator] states:</p>
-<pre> [...]
-
- private:
- // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
- // const char* delim; exposition only
-</pre>
-
-<p>Whilst it's clearly marked "exposition only", I suspect 'delim'
-should be of type 'const charT*'.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 24.5.2 [ostream.iterator], replace <tt>const char* delim</tt> with
-<tt>const charT* delim</tt>.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="352"></a>352. missing fpos requirements</h3>
-<p><b>Section:</b> 21.1.2 [char.traits.typedefs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2001-12-02</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<i>(1)</i>
-There are no requirements on the <tt>stateT</tt> template parameter of
-<tt>fpos</tt> listed in 27.4.3. The interface appears to require that
-the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
-and I think also DefaultConstructible (to implement the operations in
-Table 88).
-</p>
-<p>
-21.1.2, p3, however, only requires that
-<tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
-CopyConstructible types.
-</p>
-<p>
-<i>(2)</i>
-Additionally, the <tt>stateT</tt> template argument has no
-corresponding typedef in fpos which might make it difficult to use in
-generic code.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Modify 21.1.2, p4 from
-</p>
-<p>
- Requires: <tt>state_type</tt> shall meet the requirements of
- CopyConstructible types (20.1.3).
-</p>
-<p>
- Requires: state_type shall meet the requirements of Assignable
- (23.1, p4), CopyConstructible (20.1.3), and
- DefaultConstructible (20.1.4) types.
-</p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG feels this is two issues, as indicated above. The first is
-a defect---std::basic_fstream is unimplementable without these
-additional requirements---and the proposed resolution fixes it. The
-second is questionable; who would use that typedef? The class
-template fpos is used only in a very few places, all of which know the
-state type already. Unless motivation is provided, the second should
-be considered NAD.</p>
-
-
-
-
-
-<hr>
-<h3><a name="354"></a>354. Associative container lower/upper bound requirements</h3>
-<p><b>Section:</b> 23.1.4 [associative.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Hans Aberg <b>Date:</b> 2001-12-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Discussions in the thread "Associative container lower/upper bound
-requirements" on comp.std.c++ suggests that there is a defect in the
-C++ standard, Table 69 of section 23.1.2, "Associative containers",
-[lib.associative.reqmts]. It currently says:</p>
-
-<blockquote>
-<p>
-a.find(k): returns an iterator pointing to an element with the key equivalent to
-k, or a.end() if such an element is not found.
-</p>
-
-<p>
-a.lower_bound(k): returns an iterator pointing to the first element with
-key not less than k.
-</p>
-
-<p>
-a.upper_bound(k): returns an iterator pointing to the first element with
-key greater than k.
-</p>
-</blockquote>
-
-<p>
-We have "or a.end() if such an element is not found" for
-<tt>find</tt>, but not for <tt>upper_bound</tt> or
-<tt>lower_bound</tt>. As the text stands, one would be forced to
-insert a new element into the container and return an iterator to that
-in case the sought iterator does not exist, which does not seem to be
-the intention (and not possible with the "const" versions).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Change Table 69 of section 23.1.4 [associative.reqmts] indicated entries
-to:</p>
-
-<blockquote>
-<p>
-a.lower_bound(k): returns an iterator pointing to the first element with
-key not less than k, or a.end() if such an element is not found.
-</p>
-
-<p>
-a.upper_bound(k): returns an iterator pointing to the first element with
-key greater than k, or a.end() if such an element is not found.
-</p>
-</blockquote>
-
-<p><i>[Curaao: LWG reviewed PR.]</i></p>
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="355"></a>355. Operational semantics for a.back()</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Yaroslav Mironov <b>Date:</b> 2002-01-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>Table 68 "Optional Sequence Operations" in 23.1.1/12
-specifies operational semantics for "a.back()" as
-"*--a.end()", which may be ill-formed <i>[because calling
-operator-- on a temporary (the return) of a built-in type is
-ill-formed]</i>, provided a.end() returns a simple pointer rvalue
-(this is almost always the case for std::vector::end(), for
-example). Thus, the specification is not only incorrect, it
-demonstrates a dangerous construct: "--a.end()" may
-successfully compile and run as intended, but after changing the type
-of the container or the mode of compilation it may produce
-compile-time error. </p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the specification in table 68 "Optional Sequence
-Operations" in 23.1.1/12 for "a.back()" from</p>
-
-
-<blockquote><pre>*--a.end()
-</pre></blockquote>
-
-<p>to</p>
-
-<blockquote><pre> { iterator tmp = a.end(); --tmp; return *tmp; }
-</pre></blockquote>
-
-<p>and the specification for "a.pop_back()" from</p>
-
-<blockquote><pre>a.erase(--a.end())
-</pre></blockquote>
-
-<p>to</p>
-
-<blockquote><pre> { iterator tmp = a.end(); --tmp; a.erase(tmp); }
-</pre></blockquote>
-
-<p><i>[Curaao: LWG changed PR from "{ X::iterator tmp =
-a.end(); return *--tmp; }" to "*a.rbegin()", and from
-"{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
-"a.erase(rbegin())".]</i></p>
-
-
-<p><i>[There is a second possible defect; table 68 "Optional
-Sequence Operations" in the "Operational Semantics"
-column uses operations present only in the "Reversible
-Container" requirements, yet there is no stated dependency
-between these separate requirements tables. Ask in Santa Cruz if the
-LWG would like a new issue opened.]</i></p>
-
-
-<p><i>[Santa Cruz: the proposed resolution is even worse than what's in
- the current standard: erase is undefined for reverse iterator. If
- we're going to make the change, we need to define a temporary and
- use operator--. Additionally, we don't know how prevalent this is:
- do we need to make this change in more than one place? Martin has
- volunteered to review the standard and see if this problem occurs
- elsewhere.]</i></p>
-
-
-<p><i>[Oxford: Matt provided new wording to address the concerns raised
- in Santa Cruz. It does not appear that this problem appears
- anywhere else in clauses 23 or 24.]</i></p>
-
-
-<p><i>[Kona: In definition of operational semantics of back(), change
-"*tmp" to "return *tmp;"]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="358"></a>358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt></h3>
-<p><b>Section:</b> 22.2.2.1.2 [facet.num.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#facet.num.get.virtuals">active issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#facet.num.get.virtuals">issues</a> in [facet.num.get.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I don't think <tt>thousands_sep</tt> is being treated correctly after
-decimal_point has been seen. Since grouping applies only to the
-integral part of the number, the first such occurrence should, IMO,
-terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
-and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
-interpreted in the fractional part of a number.)
-</p>
-
-<p>
-The easiest change I can think of that resolves this issue would be
-something like below.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the first sentence of 22.2.2.1.2, p9 from
-</p>
-
-<blockquote><p>
- If discard is true then the position of the character is
- remembered, but the character is otherwise ignored. If it is not
- discarded, then a check is made to determine if c is allowed as
- the next character of an input field of the conversion specifier
- returned by stage 1. If so it is accumulated.
-</p></blockquote>
-
-<p>to</p>
-
-<blockquote><p>
- If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
- accumulated, then the position of the character is remembered, but
- the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
- already been accumulated, the character is discarded and Stage 2
- terminates. ...
-</p></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>We believe this reflects the intent of the Standard. Thousands sep
- characters after the decimal point are not useful in any locale.
- Some formatting conventions do group digits that follow the decimal
- point, but they usually introduce a different grouping character
- instead of reusing the thousand sep character. If we want to add
- support for such conventions, we need to do so explicitly.</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="359"></a>359. num_put&lt;&gt;::do_put (..., bool) undocumented</h3>
-<p><b>Section:</b> 22.2.2.2.1 [facet.num.put.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>22.2.2.2.1, p1:</p>
-
- <pre> iter_type put (iter_type out, ios_base&amp; str, char_type fill,
- bool val) const;
- ...
-
- 1 Returns: do_put (out, str, fill, val).
- </pre>
-
-<p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
-however, 22.2.2.2.2, p23:</p>
-
-<blockquote>
-<pre>iter_type put (iter_type out, ios_base&amp; str, char_type fill,
- bool val) const;
-</pre>
-
-
- <p>Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
- out = do_put(out, str, fill, (int)val)
- Otherwise do</p>
-<pre> string_type s =
- val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
- : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
-</pre>
- <p>and then insert the characters of s into out. <i>out</i>.</p>
-</blockquote>
-
-<p>
-This means that the bool overload of <tt>do_put()</tt> will never be called,
-which contradicts the first paragraph. Perhaps the declaration
-should read <tt>do_put()</tt>, and not <tt>put()</tt>?
-</p>
-
-<p>
-Note also that there is no <b>Returns</b> clause for this function, which
-should probably be corrected, just as should the second occurrence
-of <i>"out."</i> in the text.
-</p>
-
-<p>
-I think the least invasive change to fix it would be something like
-the following:
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.2.2.2.2 [facet.num.put.virtuals], just above paragraph 1, remove
- the <tt>bool</tt> overload.</p>
-
-<p>
-In 22.2.2.2.2 [facet.num.put.virtuals], p23, make the following changes
-</p>
-
-<blockquote><p>
- Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
- of the member function.
-</p></blockquote>
-
-<blockquote><p>
- Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
- avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
- do_put (..., bool))</tt>
- like so:
-</p></blockquote>
-
-<blockquote><p>
- 23 <b>Returns</b>: If <tt>(str.flags() &amp;
- ios_base::boolalpha) == 0</tt> then
- <tt>do_put (out, str, fill, (long)val)</tt>
- Otherwise the function obtains a string <tt>s</tt> as if by</p>
-<pre> string_type s =
- val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
- : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
-</pre>
- <p>and then inserts each character <tt>c</tt> of s into out via
- <tt>*out++ = c</tt>
- and returns <tt>out</tt>.</p>
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p><p>
-This fixes a couple of obvious typos, and also fixes what appears to
-be a requirement of gratuitous inefficiency.
-</p>
-
-
-
-
-<hr>
-<h3><a name="360"></a>360. locale mandates inefficient implementation</h3>
-<p><b>Section:</b> 22.1.1 [locale] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-03-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale">issues</a> in [locale].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-22.1.1, p7 (copied below) allows iostream formatters and extractors
-to make assumptions about the values returned from facet members.
-However, such assumptions are apparently not guaranteed to hold
-in other cases (e.g., when the facet members are being called directly
-rather than as a result of iostream calls, or between successive
-calls to the same iostream functions with no interevening calls to
-<tt>imbue()</tt>, or even when the facet member functions are called
-from other member functions of other facets). This restriction
-prevents locale from being implemented efficiently.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the first sentence in 22.1.1, p7 from</p>
-<blockquote><p>
- In successive calls to a locale facet member function during
- a call to an iostream inserter or extractor or a streambuf member
- function, the returned result shall be identical. [Note: This
- implies that such results may safely be reused without calling
- the locale facet member function again, and that member functions
- of iostream classes cannot safely call <tt>imbue()</tt>
- themselves, except as specified elsewhere. --end note]
-</p></blockquote>
-
-<p>to</p>
-
-<blockquote><p>
- In successive calls to a locale facet member function on a facet
- object installed in the same locale, the returned result shall be
- identical. ...
-</p></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>This change is reasonable becuase it clarifies the intent of this
- part of the standard.</p>
-
-
-
-
-
-<hr>
-<h3><a name="362"></a>362. bind1st/bind2nd type safety</h3>
-<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Andrew Demkin <b>Date:</b> 2002-04-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The definition of bind1st() (D.8 [depr.lib.binders]) can result in
-the construction of an unsafe binding between incompatible pointer
-types. For example, given a function whose first parameter type is
-'pointer to T', it's possible without error to bind an argument of
-type 'pointer to U' when U does not derive from T:
-</p>
-<pre> foo(T*, int);
-
- struct T {};
- struct U {};
-
- U u;
-
- int* p;
- int* q;
-
- for_each(p, q, bind1st(ptr_fun(foo), &amp;u)); // unsafe binding
-</pre>
-
-<p>
-The definition of bind1st() includes a functional-style conversion to
-map its argument to the expected argument type of the bound function
-(see below):
-</p>
-<pre> typename Operation::first_argument_type(x)
-</pre>
-
-<p>A functional-style conversion (D.8 [depr.lib.binders]) is defined to
-be
-semantically equivalent to an explicit cast expression (D.8
-[depr.lib.binders]), which may (according to 5.4, paragraph 5) be
-interpreted
-as a reinterpret_cast, thus masking the error.
-</p>
-
-<p>The problem and proposed change also apply to D.8 [depr.lib.binders].</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add this sentence to the end of D.8 [depr.lib.binders]/1:
- "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
- favor of <tt>std::tr1::bind</tt>."</p>
-
-<p>(Notes to editor: (1) when and if tr1::bind is incorporated into
- the standard, "std::tr1::bind" should be changed to "std::bind". (2)
- 20.5.6 should probably be moved to Annex D.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>There is no point in fixing bind1st and bind2nd. tr1::bind is a
- superior solution. It solves this problem and others.</p>
-
-
-
-
-
-<hr>
-<h3><a name="363"></a>363. Missing exception specification in 27.4.2.1.1</h3>
-<p><b>Section:</b> 27.4.2.1.1 [ios::failure] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Walter Brown and Marc Paterno <b>Date:</b> 2002-05-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ios::failure">issues</a> in [ios::failure].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The destructor of ios_base::failure should have an empty throw
-specification, because the destructor of its base class, exception, is
-declared in this way.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the destructor to</p>
-<pre> virtual ~failure() throw();
-</pre>
-
-
-<p><b>Rationale:</b></p>
-<p>Fixes an obvious glitch. This is almost editorial.</p>
-
-
-
-
-
-<hr>
-<h3><a name="364"></a>364. Inconsistent wording in 27.5.2.4.2</h3>
-<p><b>Section:</b> 27.5.2.4.2 [streambuf.virt.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#streambuf.virt.buffer">issues</a> in [streambuf.virt.buffer].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-27.5.2.4.2 [streambuf.virt.buffer] paragraph 1 is inconsistent with the Effects
-clause for seekoff.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Make this paragraph, the Effects clause for setbuf, consistent in wording
-with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
-to indicate the purpose of setbuf:
-</p>
-
-<p>Original text:</p>
-
-<blockquote><p>
-1 Effects: Performs an operation that is defined separately for each
-class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
-</p></blockquote>
-
-<p>Proposed text:</p>
-
-<blockquote><p>
-1 Effects: Influences stream buffering in a way that is defined separately
-for each class derived from basic_streambuf in this clause
-(27.7.1.3, 27.8.1.4).
-</p></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG doesn't believe there is any normative difference between
- the existing wording and what's in the proposed resolution, but the
- change may make the intent clearer.</p>
-
-
-
-
-
-<hr>
-<h3><a name="365"></a>365. Lack of const-qualification in clause 27</h3>
-<p><b>Section:</b> 27 [input.output] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 2002-05-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#input.output">issues</a> in [input.output].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Some stream and streambuf member functions are declared non-const,
-even thought they appear only to report information rather than to
-change an object's logical state. They should be declared const. See
-document N1360 for details and rationale.
-</p>
-
-<p>The list of member functions under discussion: <tt>in_avail</tt>,
-<tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
-
-<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
-<p>Replace</p>
-<pre> bool is_open();
-</pre>
-<p>with</p>
-<pre> bool is_open() const;
-</pre>
-
-
-<p><b>Rationale:</b></p>
-<p>Of the changes proposed in N1360, the only one that is safe is
-changing the filestreams' is_open to const. The LWG believed that
-this was NAD the first time it considered this issue (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a>), but now thinks otherwise. The corresponding streambuf
-member function, after all,is already const.</p>
-
-<p>The other proposed changes are less safe, because some streambuf
-functions that appear merely to report a value do actually perform
-mutating operations. It's not even clear that they should be
-considered "logically const", because streambuf has two interfaces, a
-public one and a protected one. These functions may, and often do,
-change the state as exposed by the protected interface, even if the
-state exposed by the public interface is unchanged.</p>
-
-<p>Note that implementers can make this change in a binary compatible
-way by providing both overloads; this would be a conforming extension.</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="369"></a>369. io stream objects and static ctors</h3>
-<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 2002-07-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Is it safe to use standard iostream objects from constructors of
-static objects? Are standard iostream objects constructed and are
-their associations established at that time?
-</p>
-
-<p>Surpisingly enough, Standard does NOT require that.</p>
-
-<p>
-27.3/2 [lib.iostream.objects] guarantees that standard iostream
-objects are constructed and their associations are established before
-the body of main() begins execution. It also refers to ios_base::Init
-class as the panacea for constructors of static objects.
-</p>
-
-<p>
-However, there's nothing in 27.3 [lib.iostream.objects],
-in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
-that would require implementations to allow access to standard
-iostream objects from constructors of static objects.
-</p>
-
-<p>Details:</p>
-
-<p>Core text refers to some magic object ios_base::Init, which will
-be discussed below:</p>
-
-<blockquote><p>
- "The [standard iostream] objects are constructed, and their
- associations are established at some time prior to or during
- first time an object of class basic_ios&lt;charT,traits&gt;::Init
- is constructed, and in any case before the body of main
- begins execution." (27.3/2 [lib.iostream.objects])
-</p></blockquote>
-
-<p>
-The first <i>non-normative</i> footnote encourages implementations
-to initialize standard iostream objects earlier than required.
-</p>
-
-<p>However, the second <i>non-normative</i> footnote makes an explicit
-and unsupported claim:</p>
-
-<blockquote><p>
- "Constructors and destructors for static objects can access these
- [standard iostream] objects to read input from stdin or write output
- to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
-</p></blockquote>
-
-<p>
-The only bit of magic is related to that ios_base::Init class. AFAIK,
-the rationale behind ios_base::Init was to bring an instance of this
-class to each translation unit which #included &lt;iostream&gt; or
-related header. Such an inclusion would support the claim of footnote
-quoted above, because in order to use some standard iostream object it
-is necessary to #include &lt;iostream&gt;.
-</p>
-
-<p>
-However, while Standard explicitly describes ios_base::Init as
-an appropriate class for doing the trick, I failed to found a
-mention of an _instance_ of ios_base::Init in Standard.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Add to 27.3 [iostream.objects], p2, immediately before the last sentence
-of the paragraph, the following two sentences:</p>
-
-<blockquote><p>
-If a translation unit includes &lt;iostream&gt;, or explicitly
-constructs an ios_base::Init object, these stream objects shall
-be constructed before dynamic initialization of non-local
-objects defined later in that translation unit, and these stream
-objects shall be destroyed after the destruction of dynamically
-initialized non-local objects defined later in that translation unit.
-</p></blockquote>
-
-<p><i>[Lillehammer: Matt provided wording.]</i></p>
-
-<p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-The original proposed resolution unconditionally required
-implementations to define an ios_base::Init object of some
-implementation-defined name in the header &lt;iostream&gt;. That's an
-overspecification. First, defining the object may be unnecessary
-and even detrimental to performance if an implementation can
-guarantee that the 8 standard iostream objects will be initialized
-before any other user-defined object in a program. Second, there
-is no need to require implementations to document the name of the
-object.</p>
-
-<p>
-The new proposed resolution gives users guidance on what they need to
-do to ensure that stream objects are constructed during startup.</p>
-
-
-
-
-
-<hr>
-<h3><a name="370"></a>370. Minor error in basic_istream::get</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-07-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Defect report for description of basic_istream::get (section
-27.6.1.3 [istream.unformatted]), paragraph 15. The description for the
-get function
-with the following signature:</p>
-
-<pre> basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
- sb);
-</pre>
-
-<p>is incorrect. It reads</p>
-
-<blockquote><p>
- Effects: Calls get(s,n,widen('\n'))
-</p></blockquote>
-
-<p>which I believe should be:</p>
-
-<blockquote><p>
- Effects: Calls get(sb,widen('\n'))
-</p></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the <b>Effects</b> paragraph to:</p>
-<blockquote><p>
- Effects: Calls get(sb,this-&gt;widen('\n'))
-</p></blockquote>
-
-<p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen'
- with 'this-&gt;widen'.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>
-
-
-
-
-<hr>
-<h3><a name="371"></a>371. Stability of multiset and multimap member functions</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Frank Compagner <b>Date:</b> 2002-07-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The requirements for multiset and multimap containers (23.1
-[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
-23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
-the stability of the required (mutating) member functions. It appears
-the standard allows these functions to reorder equivalent elements of
-the container at will, yet the pervasive red-black tree implementation
-appears to provide stable behaviour.
-</p>
-
-<p>This is of most concern when considering the behaviour of erase().
-A stability requirement would guarantee the correct working of the
-following 'idiom' that removes elements based on a certain predicate
-function.
-</p>
-
-<pre> multimap&lt;int, int&gt; m;
- multimap&lt;int, int&gt;::iterator i = m.begin();
- while (i != m.end()) {
- if (pred(i))
- m.erase (i++);
- else
- ++i;
- }
-</pre>
-
-<p>
-Although clause 23.1.2/8 guarantees that i remains a valid iterator
-througout this loop, absence of the stability requirement could
-potentially result in elements being skipped. This would make
-this code incorrect, and, furthermore, means that there is no way
-of erasing these elements without iterating first over the entire
-container, and second over the elements to be erased. This would
-be unfortunate, and have a negative impact on both performance and
-code simplicity.
-</p>
-
-<p>
-If the stability requirement is intended, it should be made explicit
-(probably through an extra paragraph in clause 23.1.2).
-</p>
-<p>
-If it turns out stability cannot be guaranteed, i'd argue that a
-remark or footnote is called for (also somewhere in clause 23.1.2) to
-warn against relying on stable behaviour (as demonstrated by the code
-above). If most implementations will display stable behaviour, any
-problems emerging on an implementation without stable behaviour will
-be hard to track down by users. This would also make the need for an
-erase_if() member function that much greater.
-</p>
-
-<p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Add the following to the end of 23.1.4 [associative.reqmts] paragraph 4:
-"For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
- are <i>stable</i>: they preserve the relative ordering of equivalent
- elements.</p>
-
-<p><i>[Lillehammer: Matt provided wording]</i></p>
-
-<p><i>[Joe Gottman points out that the provided wording does not address
-multimap and multiset. N1780 also addresses this issue and suggests
-wording.]</i></p>
-
-
-<p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG agrees that this guarantee is necessary for common user
- idioms to work, and that all existing implementations provide this
- property. Note that this resolution guarantees stability for
- multimap and multiset, not for all associative containers in
- general.</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="373"></a>373. Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3>
-<p><b>Section:</b> 27.6.1.2.1 [istream.formatted.reqmts], 27.6.2.6.1 [ostream.formatted.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Keith Baker <b>Date:</b> 2002-07-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.reqmts">issues</a> in [istream.formatted.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts]
-(exception()&amp;badbit) != 0 is used in testing for rethrow, yet
-exception() is the constructor to class std::exception in 18.6.1 [type.info] that has no return type. Should member function
-exceptions() found in 27.4.4 [ios] be used instead?
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.6.1.2.1 [istream.formatted.reqmts] and 27.6.2.6.1 [ostream.formatted.reqmts], change
-"(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>Fixes an obvious typo.</p>
-
-
-
-
-
-<hr>
-<h3><a name="375"></a>375. basic_ios should be ios_base in 27.7.1.3</h3>
-<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In Section 27.7.1.4 [stringbuf.virtuals]: Table 90, Table 91, and paragraph
-14 all contain references to "basic_ios::" which should be
-"ios_base::".
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change all references to "basic_ios" in Table 90, Table 91, and
-paragraph 14 to "ios_base".
-</p>
-
-
-<p><b>Rationale:</b></p><p>Fixes an obvious typo.</p>
-
-
-
-
-<hr>
-<h3><a name="376"></a>376. basic_streambuf semantics</h3>
-<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Ray Lischner <b>Date:</b> 2002-08-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In Section 27.7.1.4 [stringbuf.virtuals], Table 90, the implication is that
-the four conditions should be mutually exclusive, but they are not.
-The first two cases, as written, are subcases of the third.</p>
-
-<p>
-As written, it is unclear what should be the result if cases 1 and 2
-are both true, but case 3 is false.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Rewrite these conditions as:</p>
-<blockquote>
-<p>
- (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
-</p>
-
-<p>
- (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
-</p>
-
-<p>
- (which &amp; (ios_base::in|ios_base::out)) ==
-(ios_base::in|ios_base::out)
- and way == either ios_base::beg or ios_base::end
-</p>
-
-<p>Otherwise</p>
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>It's clear what we wanted to say, we just failed to say it. This
- fixes it.</p>
-
-
-
-
-
-<hr>
-<h3><a name="379"></a>379. nonsensical ctype::do_widen() requirement</h3>
-<p><b>Section:</b> 22.2.1.1.2 [locale.ctype.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.virtuals">issues</a> in [locale.ctype.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
-</p>
-<pre> charT do_widen (char c) const;
-
- -11- Effects: Applies the simplest reasonable transformation from
- a char value or sequence of char values to the corresponding
- charT value or values. The only characters for which unique
- transformations are required are those in the basic source
- character set (2.2). For any named ctype category with a
- ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
- M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
-</pre>
-<p>
-Shouldn't the last sentence instead read
-</p>
-<pre> For any named ctype category with a ctype&lt;char&gt; facet ctc
- and valid ctype_base::mask value M
- (ctc.is(M, c) || !is(M, do_widen(c))) is true.
-</pre>
-<p>
-I.e., if the narrow character c is not a member of a class of
-characters then neither is the widened form of c. (To paraphrase
-footnote 224.)
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Replace the last sentence of 22.2.1.1.2 [locale.ctype.virtuals], p11 with the
-following text:
-</p>
-<pre> For any named ctype category with a ctype&lt;char&gt; facet ctc
- and valid ctype_base::mask value M,
- (ctc.is(M, c) || !is(M, do_widen(c))) is true.
-</pre>
-
-<p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes this is just a typo, and that this is the correct fix.</p>
-
-
-
-
-
-<hr>
-<h3><a name="380"></a>380. typos in codecvt tables 53 and 54</h3>
-<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Tables 53 and 54 in 22.2.1.5 [locale.codecvt.byname] are both titled "convert
-result values," when surely "do_in/do_out result values" must have
-been intended for Table 53 and "do_unshift result values" for Table
-54.
-</p>
-<p>
-Table 54, row 3 says that the meaning of partial is "more characters
-needed to be supplied to complete termination." The function is not
-supplied any characters, it is given a buffer which it fills with
-characters or, more precisely, destination elements (i.e., an escape
-sequence). So partial means that space for more than (to_limit - to)
-destination elements was needed to terminate a sequence given the
-value of state.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the title of Table 53 to "do_in/do_out result values" and
-the title of Table 54 to "do_unshift result values."
-</p>
-<p>
-Change the text in Table 54, row 3 (the <b>partial</b> row), under the
-heading Meaning, to "space for more than (to_limit - to) destination
-elements was needed to terminate a sequence given the value of state."
-</p>
-
-
-
-
-<hr>
-<h3><a name="381"></a>381. detection of invalid mbstate_t in codecvt</h3>
-<p><b>Section:</b> 22.2.1.5 [locale.codecvt.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2002-09-06</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.byname">issues</a> in [locale.codecvt.byname].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-All but one codecvt member functions that take a state_type argument
-list as one of their preconditions that the state_type argument have
-a valid value. However, according to 22.2.1.5.2, p6,
-codecvt::do_unshift() is the only codecvt member that is supposed to
-return error if the state_type object is invalid.
-</p>
-
-<p>
-It seems to me that the treatment of state_type by all codecvt member
-functions should be the same and the current requirements should be
-changed. Since the detection of invalid state_type values may be
-difficult in general or computationally expensive in some specific
-cases, I propose the following:
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a new paragraph before 22.2.1.5.2, p5, and after the function
-declaration below
-</p>
-<pre> result do_unshift(stateT&amp; state,
- externT* to, externT* to_limit, externT*&amp; to_next) const;
-</pre>
-<p>
-as follows:
-</p>
-<pre> Requires: (to &lt;= to_end) well defined and true; state initialized,
- if at the beginning of a sequence, or else equal to the result of
- converting the preceding characters in the sequence.
-</pre>
-<p>
-and change the text in Table 54, row 4, the <b>error</b> row, under
-the heading Meaning, from
-</p>
-<pre> state has invalid value
-</pre>
-<p>
-to
-</p>
-<pre> an unspecified error has occurred
-</pre>
-
-
-<p><b>Rationale:</b></p>
-<p>The intent is that implementations should not be required to detect
-invalid state values; such a requirement appears nowhere else. An
-invalid state value is a precondition violation, <i>i.e.</i> undefined
-behavior. Implementations that do choose to detect invalid state
-values, or that choose to detect any other kind of error, may return
-<b>error</b> as an indication.</p>
-
-
-
-
-
-<hr>
-<h3><a name="383"></a>383. Bidirectional iterator assertion typo</h3>
-<p><b>Section:</b> 24.1.4 [bidirectional.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> ysapir (submitted via comp.std.c++) <b>Date:</b> 2002-10-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bidirectional.iterators">issues</a> in [bidirectional.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Following a discussion on the boost list regarding end iterators and
-the possibility of performing operator--() on them, it seems to me
-that there is a typo in the standard. This typo has nothing to do
-with that discussion.
-</p>
-
-<p>
-I have checked this newsgroup, as well as attempted a search of the
-Active/Defect/Closed Issues List on the site for the words "s is
-derefer" so I believe this has not been proposed before. Furthermore,
-the "Lists by Index" mentions only DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> on section
-24.1.4, and DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> is not related to this issue.
-</p>
-
-<p>
-The standard makes the following assertion on bidirectional iterators,
-in section 24.1.4 [lib.bidirectional.iterators], Table 75:
-</p>
-
-<pre> operational assertion/note
-expression return type semantics pre/post-condition
-
---r X&amp; pre: there exists s such
- that r == ++s.
- post: s is dereferenceable.
- --(++r) == r.
- --r == --s implies r == s.
- &amp;r == &amp;--r.
-</pre>
-
-<p>
-(See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
-</p>
-
-<p>
-In particular, "s is dereferenceable" seems to be in error. It seems
-that the intention was to say "r is dereferenceable".
-</p>
-
-<p>
-If it were to say "r is dereferenceable" it would
-make perfect sense. Since s must be dereferenceable prior to
-operator++, then the natural result of operator-- (to undo operator++)
-would be to make r dereferenceable. Furthermore, without other
-assertions, and basing only on precondition and postconditions, we
-could not otherwise know this. So it is also interesting information.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the guarantee to "postcondition: r is dereferenceable."
-</p>
-
-
-<p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
-
-
-
-
-<hr>
-<h3><a name="384"></a>384. equal_range has unimplementable runtime complexity</h3>
-<p><b>Section:</b> 25.3.3.3 [equal.range] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Hans Bos <b>Date:</b> 2002-10-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#equal.range">issues</a> in [equal.range].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 25.3.3.3 [equal.range]
-states that at most 2 * log(last - first) + 1
-comparisons are allowed for equal_range.
-</p>
-
-<p>It is not possible to implement equal_range with these constraints.</p>
-
-<p>In a range of one element as in:</p>
-<pre> int x = 1;
- equal_range(&amp;x, &amp;x + 1, 1)
-</pre>
-
-<p>it is easy to see that at least 2 comparison operations are needed.</p>
-
-<p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
-
-<p>I have checked a few libraries and they all use the same (nonconforming)
-algorithm for equal_range that has a complexity of</p>
-<pre> 2* log(distance(first, last)) + 2.
-</pre>
-<p>I guess this is the algorithm that the standard assumes for equal_range.</p>
-
-<p>
-It is easy to see that 2 * log(distance) + 2 comparisons are enough
-since equal range can be implemented with lower_bound and upper_bound
-(both log(distance) + 1).
-</p>
-
-<p>
-I think it is better to require something like 2log(distance) + O(1) (or
-even logarithmic as multiset::equal_range).
-Then an implementation has more room to optimize for certain cases (e.g.
-have log(distance) characteristics when at most match is found in the range
-but 2log(distance) + 4 for the worst case).
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 25.3.3.1 [lower.bound]/4, change <tt>log(last - first) + 1</tt>
-to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
-
-<p>In 25.3.3.2 [upper.bound]/4, change <tt>log(last - first) + 1</tt>
-to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
-
-<p>In 25.3.3.3 [equal.range]/4, change <tt>2*log(last - first) + 1</tt>
-to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
-
-<p><i>[Matt provided wording]</i></p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG considered just saying <i>O</i>(log n) for all three, but
- decided that threw away too much valuable information. The fact
- that lower_bound is twice as fast as equal_range is important.
- However, it's better to allow an arbitrary additive constant than to
- specify an exact count. An exact count would have to
- involve <tt>floor</tt> or <tt>ceil</tt>. It would be too easy to
- get this wrong, and don't provide any substantial value for users.</p>
-
-
-
-
-<hr>
-<h3><a name="386"></a>386. Reverse iterator's operator[] has impossible return type</h3>
-<p><b>Section:</b> 24.4.1.3.11 [reverse.iter.op-=] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2002-10-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In 24.4.1.3.11 [reverse.iter.op-=], <tt>reverse_iterator&lt;&gt;::operator[]</tt>
-is specified as having a return type of <tt>reverse_iterator::reference</tt>,
-which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
-(Where <tt>Iterator</tt> is the underlying iterator type.)</p>
-
-<p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
- necessarily have a return type
- of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>. Its
- return type is merely required to be convertible
- to <tt>Iterator</tt>'s value type. The return type specified for
- reverse_iterator's operator[] would thus appear to be impossible.</p>
-
-<p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, the type of
- <tt>a[n]</tt> will continue to be required (for random access
- iterators) to be convertible to the value type, and also <tt>a[n] =
- t</tt> will be a valid expression. Implementations of
- <tt>reverse_iterator</tt> will likely need to return a proxy from
- <tt>operator[]</tt> to meet these requirements. As mentioned in the
- comment from Dave Abrahams, the simplest way to specify that
- <tt>reverse_iterator</tt> meet this requirement to just mandate
- it and leave the return type of <tt>operator[]</tt> unspecified.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>In 24.4.1.2 [reverse.iter.requirements] change:</p>
-
-<blockquote>
-<pre>reference operator[](difference_type n) const;
-</pre>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see 24.1.5 [random.access.iterators]
-</pre>
-</blockquote>
-
-
-
-
-<p><i>[
-Comments from Dave Abrahams: IMO we should resolve 386 by just saying
- that the return type of reverse_iterator's operator[] is
- unspecified, allowing the random access iterator requirements to
- impose an appropriate return type. If we accept 299's proposed
- resolution (and I think we should), the return type will be
- readable and writable, which is about as good as we can do.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="389"></a>389. Const overload of valarray::operator[] returns by value</h3>
-<p><b>Section:</b> 26.5.2.3 [valarray.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2002-11-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.access">issues</a> in [valarray.access].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#77">77</a></p>
-<p><b>Discussion:</b></p>
-<p>Consider the following program:</p>
-<pre> #include &lt;iostream&gt;
- #include &lt;ostream&gt;
- #include &lt;vector&gt;
- #include &lt;valarray&gt;
- #include &lt;algorithm&gt;
- #include &lt;iterator&gt;
- template&lt;typename Array&gt;
- void print(const Array&amp; a)
- {
- using namespace std;
- typedef typename Array::value_type T;
- copy(&amp;a[0], &amp;a[0] + a.size(),
- ostream_iterator&lt;T&gt;(std::cout, " "));
- }
- template&lt;typename T, unsigned N&gt;
- unsigned size(T(&amp;)[N]) { return N; }
- int main()
- {
- double array[] = { 0.89, 9.3, 7, 6.23 };
- std::vector&lt;double&gt; v(array, array + size(array));
- std::valarray&lt;double&gt; w(array, size(array));
- print(v); // #1
- std::cout &lt;&lt; std::endl;
- print(w); // #2
- std::cout &lt;&lt; std::endl;
- }
-</pre>
-
-<p>While the call numbered #1 succeeds, the call numbered #2 fails
-because the const version of the member function
-valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
-const-reference. That seems to be so for no apparent reason, no
-benefit. Not only does that defeats users' expectation but it also
-does hinder existing software (written either in C or Fortran)
-integration within programs written in C++. There is no reason why
-subscripting an expression of type valarray&lt;T&gt; that is const-qualified
-should not return a const T&amp;.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In the class synopsis in 26.5.2 [template.valarray], and in
-26.5.2.3 [valarray.access] just above paragraph 1, change</p>
-<pre> T operator[](size_t const);
-</pre>
-<p>to</p>
-<pre> const T&amp; operator[](size_t const);
-</pre>
-
-<p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
- wehre it belongs.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>Return by value seems to serve no purpose. Valaray was explicitly
-designed to have a specified layout so that it could easily be
-integrated with libraries in other languages, and return by value
-defeats that purpose. It is believed that this change will have no
-impact on allowable optimizations.</p>
-
-
-
-
-
-<hr>
-<h3><a name="391"></a>391. non-member functions specified as const</h3>
-<p><b>Section:</b> 22.1.3.2 [conversions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> James Kanze <b>Date:</b> 2002-12-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The specifications of toupper and tolower both specify the functions as
-const, althought they are not member functions, and are not specified as
-const in the header file synopsis in section 22.1 [locales].
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 22.1.3.2 [conversions], remove <tt>const</tt> from the function
- declarations of std::toupper and std::tolower</p>
-
-
-<p><b>Rationale:</b></p><p>Fixes an obvious typo</p>
-
-
-
-
-<hr>
-<h3><a name="395"></a>395. inconsistencies in the definitions of rand() and random_shuffle()</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> James Kanze <b>Date:</b> 2003-01-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 26.7 [c.math], the C++ standard refers to the C standard for the
-definition of rand(); in the C standard, it is written that "The
-implementation shall behave as if no library function calls the rand
-function."
-</p>
-
-<p>
-In 25.2.12 [alg.random.shuffle], there is no specification as to
-how the two parameter version of the function generates its random
-value. I believe that all current implementations in fact call rand()
-(in contradiction with the requirement avove); if an implementation does
-not call rand(), there is the question of how whatever random generator
-it does use is seeded. Something is missing.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In [lib.c.math], add a paragraph specifying that the C definition of
-rand shal be modified to say that "Unless otherwise specified, the
-implementation shall behave as if no library function calls the rand
-function."
-</p>
-
-<p>
-In [lib.alg.random.shuffle], add a sentence to the effect that "In
-the two argument form of the function, the underlying source of
-random numbers is implementation defined. [Note: in particular, an
-implementation is permitted to use <tt>rand</tt>.]
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The original proposed resolution proposed requiring the
- two-argument from of <tt>random_shuffle</tt> to
- use <tt>rand</tt>. We don't want to do that, because some existing
- implementations already use something else: gcc
- uses <tt>lrand48</tt>, for example. Using <tt>rand</tt> presents a
- problem if the number of elements in the sequence is greater than
- RAND_MAX.</p>
-
-
-
-
-
-<hr>
-<h3><a name="400"></a>400. redundant type cast in lib.allocator.members</h3>
-<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-20.7.5.1 [allocator.members] allocator members, contains
-the following 3 lines:
-</p>
-
-<pre> 12 Returns: new((void *) p) T( val)
- void destroy(pointer p);
- 13 Returns: ((T*) p)-&gt;~T()
-</pre>
-
-<p>
-The type cast "(T*) p" in the last line is redundant cause
-we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Replace "((T*) p)" with "p".
-</p>
-
-
-<p><b>Rationale:</b></p><p>Just a typo, this is really editorial.</p>
-
-
-
-
-<hr>
-<h3><a name="401"></a>401. incorrect type casts in table 32 in lib.allocator.requirements</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I think that in par2 of [default.con.req] the last two
-lines of table 32 contain two incorrect type casts. The lines are ...
-</p>
-
-<pre> a.construct(p,t) Effect: new((void*)p) T(t)
- a.destroy(p) Effect: ((T*)p)?-&gt;~T()
-</pre>
-
-<p>
-.... with the prerequisits coming from the preceding two paragraphs, especially
-from table 31:
-</p>
-
-<pre> alloc&lt;T&gt; a ;// an allocator for T
- alloc&lt;T&gt;::pointer p ;// random access iterator
- // (may be different from T*)
- alloc&lt;T&gt;::reference r = *p;// T&amp;
- T const&amp; t ;
-</pre>
-
-<p>
-For that two type casts ("(void*)p" and "(T*)p") to be well-formed
-this would require then conversions to T* and void* for all
-alloc&lt;T&gt;::pointer, so it would implicitely introduce extra
-requirements for alloc&lt;T&gt;::pointer, additionally to the only
-current requirement (being a random access iterator).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Accept proposed wording from
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2436.pdf">N2436</a> part 1.
-</p>
-
-<p>
-Note: Actually I would prefer to replace "((T*)p)?-&gt;dtor_name" with
-"p?-&gt;dtor_name", but AFAICS this is not possible cause of an omission
-in 13.5.6 [over.ref] (for which I have filed another DR on 29.11.2002).
-</p>
-
-<p><i>[Kona: The LWG thinks this is somewhere on the border between
- Open and NAD. The intend is clear: <tt>construct</tt> constructs an
- object at the location <i>p</i>. It's reading too much into the
- description to think that literally calling <tt>new</tt> is
- required. Tweaking this description is low priority until we can do
- a thorough review of allocators, and, in particular, allocators with
- non-default pointer types.]</i></p>
-
-
-<p><i>[
-Batavia: Proposed resolution changed to less code and more description.
-]</i></p>
-
-
-<p><i>[
-post Oxford: This would be rendered NAD Editorial by acceptance of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
-]</i></p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
-was subsequently split out into a separate paper N2436 for the purposes of voting.
-The resolution in N2436 addresses this issue. The LWG voted to accelerate this
-issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="402"></a>402. wrong new expression in [some_]allocator::construct</h3>
-<p><b>Section:</b> 20.1.2 [allocator.requirements], 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Markus Mauhart <b>Date:</b> 2003-02-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-This applies to the new expression that is contained in both par12 of
-20.7.5.1 [allocator.members] and in par2 (table 32) of [default.con.req].
-I think this new expression is wrong, involving unintended side
-effects.
-</p>
-
-
-<p>20.7.5.1 [allocator.members] contains the following 3 lines:</p>
-
-<pre> 11 Returns: the largest value N for which the call allocate(N,0) might succeed.
- void construct(pointer p, const_reference val);
- 12 Returns: new((void *) p) T( val)
-</pre>
-
-
-<p> [default.con.req] in table 32 has the following line:</p>
-<pre> a.construct(p,t) Effect: new((void*)p) T(t)
-</pre>
-
-<p>
-.... with the prerequisits coming from the preceding two paragraphs,
-especially from table 31:
-</p>
-
-<pre> alloc&lt;T&gt; a ;// an allocator for T
- alloc&lt;T&gt;::pointer p ;// random access iterator
- // (may be different from T*)
- alloc&lt;T&gt;::reference r = *p;// T&amp;
- T const&amp; t ;
-</pre>
-
-<p>
-Cause of using "new" but not "::new", any existing "T::operator new"
-function will hide the global placement new function. When there is no
-"T::operator new" with adequate signature,
-every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
-std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
-would be adding placement new and delete functions with adequate
-signature and semantic to class T, but class T might come from another
-party. Maybe even worse is the case when T has placement new and
-delete functions with adequate signature but with "unknown" semantic:
-I dont like to speculate about it, but whoever implements
-any_container&lt;T,any_alloc&gt; and wants to use construct(..)
-probably must think about it.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Replace "new" with "::new" in both cases.
-</p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="403"></a>403. basic_string::swap should not throw exceptions</h3>
-<p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2003-03-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-std::basic_string, 21.3 [basic.string] paragraph 2 says that
-basic_string "conforms to the requirements of a Sequence, as specified
-in (23.1.1)." The sequence requirements specified in (23.1.1) to not
-include any prohibition on swap members throwing exceptions.
-</p>
-
-<p>
-Section 23.1 [container.requirements] paragraph 10 does limit conditions under
-which exceptions may be thrown, but applies only to "all container
-types defined in this clause" and so excludes basic_string::swap
-because it is defined elsewhere.
-</p>
-
-<p>
-Eric Niebler points out that 21.3 [basic.string] paragraph 5 explicitly
-permits basic_string::swap to invalidates iterators, which is
-disallowed by 23.1 [container.requirements] paragraph 10. Thus the standard would
-be contradictory if it were read or extended to read as having
-basic_string meet 23.1 [container.requirements] paragraph 10 requirements.
-</p>
-
-<p>
-Yet several LWG members have expressed the belief that the original
-intent was that basic_string::swap should not throw exceptions as
-specified by 23.1 [container.requirements] paragraph 10, and that the standard is
-unclear on this issue. The complexity of basic_string::swap is
-specified as "constant time", indicating the intent was to avoid
-copying (which could cause a bad_alloc or other exception). An
-important use of swap is to ensure that exceptions are not thrown in
-exception-safe code.
-</p>
-
-<p>
-Note: There remains long standing concern over whether or not it is
-possible to reasonably meet the 23.1 [container.requirements] paragraph 10 swap
-requirements when allocators are unequal. The specification of
-basic_string::swap exception requirements is in no way intended to
-address, prejudice, or otherwise impact that concern.
-</p>
-
-
-
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 21.3.6.8 [string::swap], add a throws clause:
-</p>
-
-<p>
-Throws: Shall not throw exceptions.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="404"></a>404. May a replacement allocation function be declared inline?</h3>
-<p><b>Section:</b> 17.4.3.5 [replacement.functions], 18.5.1 [new.delete] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-04-24</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The eight basic dynamic memory allocation functions (single-object
-and array versions of ::operator new and ::operator delete, in the
-ordinary and nothrow forms) are replaceable. A C++ program may
-provide an alternative definition for any of them, which will be used
-in preference to the implementation's definition.
-</p>
-
-<p>
-Three different parts of the standard mention requirements on
-replacement functions: 17.4.3.5 [replacement.functions], 18.5.1.1 [new.delete.single]
-and 18.5.1.2 [new.delete.array], and 3.7.2 [basic.stc.auto].
-</p>
-
-<p>None of these three places say whether a replacement function may
- be declared inline. 18.5.1.1 [new.delete.single] paragraph 2 specifies a
- signature for the replacement function, but that's not enough:
- the <tt>inline</tt> specifier is not part of a function's signature.
- One might also reason from 7.1.2 [dcl.fct.spec] paragraph 2, which
- requires that "an inline function shall be defined in every
- translation unit in which it is used," but this may not be quite
- specific enough either. We should either explicitly allow or
- explicitly forbid inline replacement memory allocation
- functions.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a new sentence to the end of 17.4.3.5 [replacement.functions] paragraph 3:
-"The program's definitions shall not be specified as <tt>inline</tt>.
-No diagnostic is required."
-</p>
-
-<p><i>[Kona: added "no diagnostic is required"]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-The fact that <tt>inline</tt> isn't mentioned appears to have been
-nothing more than an oversight. Existing implementations do not
-permit inline functions as replacement memory allocation functions.
-Providing this functionality would be difficult in some cases, and is
-believed to be of limited value.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="405"></a>405. qsort and POD</h3>
-<p><b>Section:</b> 25.4 [alg.c.library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Ray Lischner <b>Date:</b> 2003-04-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.c.library">issues</a> in [alg.c.library].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 25.4 [alg.c.library] describes bsearch and qsort, from the C
-standard library. Paragraph 4 does not list any restrictions on qsort,
-but it should limit the base parameter to point to POD. Presumably,
-qsort sorts the array by copying bytes, which requires POD.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 25.4 [alg.c.library] paragraph 4, just after the declarations and
-before the nonnormative note, add these words: "both of which have the
-same behavior as the original declaration. The behavior is undefined
-unless the objects in the array pointed to by <i>base</i> are of POD
-type."
-</p>
-
-<p><i>[Something along these lines is clearly necessary. Matt
- provided wording.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="406"></a>406. vector::insert(s) exception safety</h3>
-<p><b>Section:</b> 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2003-04-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-There is a possible defect in the standard: the standard text was
-never intended to prevent arbitrary ForwardIterators, whose operations
-may throw exceptions, from being passed, and it also wasn't intended
-to require a temporary buffer in the case where ForwardIterators were
-passed (and I think most implementations don't use one). As is, the
-standard appears to impose requirements that aren't met by any
-existing implementation.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace 23.2.6.4 [vector.modifiers] paragraph 1 with:</p>
-<blockquote><p>
- 1- Notes: Causes reallocation if the new size is greater than the
- old capacity. If no reallocation happens, all the iterators and
- references before the insertion point remain valid. If an exception
- is thrown other than by the copy constructor or assignment operator
- of T or by any InputIterator operation there are no effects.
-</p></blockquote>
-
-<p><i>[We probably need to say something similar for deque.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="407"></a>407. Can singular iterators be destroyed?</h3>
-<p><b>Section:</b> 24.1 [iterator.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Clause 24.1 [iterator.requirements], paragraph 5, says that the only expression
-that is defined for a singular iterator is "an assignment of a
-non-singular value to an iterator that holds a singular value". This
-means that destroying a singular iterator (e.g. letting an automatic
-variable go out of scope) is technically undefined behavior. This
-seems overly strict, and probably unintentional.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the sentence in question to "... the only exceptions are
-destroying an iterator that holds a singular value, or the assignment
-of a non-singular value to an iterator that holds a singular value."
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="409"></a>409. Closing an fstream should clear error state</h3>
-<p><b>Section:</b> 27.8.1.9 [ifstream.members], 27.8.1.13 [ofstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Nathan Myers <b>Date:</b> 2003-06-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ifstream.members">issues</a> in [ifstream.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-A strict reading of 27.8.1 [fstreams] shows that opening or
-closing a basic_[io]fstream does not affect the error bits. This
-means, for example, that if you read through a file up to EOF, and
-then close the stream and reopen it at the beginning of the file,
-the EOF bit in the stream's error state is still set. This is
-counterintuitive.
-</p>
-<p>
-The LWG considered this issue once before, as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>,
-and put in a footnote to clarify that the strict reading was indeed
-correct. We did that because we believed the standard was
-unambiguous and consistent, and that we should not make architectural
-changes in a TC. Now that we're working on a new revision of the
-language, those considerations no longer apply.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Change 27.8.1.9 [ifstream.members], para. 3 from:</p>
-
-<blockquote><p>
-Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null
-pointer, calls setstate(failbit) (which may throw ios_base::failure
-[Footnote: (lib.iostate.flags)].
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>Calls rdbuf()-&gt;open(s,mode|in). If that function
-returns a null pointer, calls setstate(failbit) (which may throw
-ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
-</p></blockquote>
-
-<p>Change 27.8.1.13 [ofstream.members], para. 3 from:</p>
-
-<blockquote><p>Calls rdbuf()-&gt;open(s,mode|out). If that function
-returns a null pointer, calls setstate(failbit) (which may throw
-ios_base::failure [Footnote: (lib.iostate.flags)).
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>Calls rdbuf()-&gt;open(s,mode|out). If that function
-returns a null pointer, calls setstate(failbit) (which may throw
-ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
-</p></blockquote>
-
-<p>Change 27.8.1.17 [fstream.members], para. 3 from:</p>
-
-<blockquote><p>Calls rdbuf()-&gt;open(s,mode), If that function returns
-a null pointer, calls setstate(failbit), (which may throw
-ios_base::failure). (lib.iostate.flags) )
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>Calls rdbuf()-&gt;open(s,mode), If that function returns
-a null pointer, calls setstate(failbit), (which may throw
-ios_base::failure). (lib.iostate.flags) ), else calls clear().
-</p></blockquote>
-
-
-
-<p><i>[Kona: the LWG agrees this is a good idea. Post-Kona: Bill
-provided wording. He suggests having open, not close, clear the error
-flags.]</i></p>
-
-
-<p><i>[Post-Sydney: Howard provided a new proposed resolution. The
- old one didn't make sense because it proposed to fix this at the
- level of basic_filebuf, which doesn't have access to the stream's
- error state. Howard's proposed resolution fixes this at the level
- of the three fstream class template instead.]</i></p>
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="410"></a>410. Missing semantics for stack and queue comparison operators</h3>
-<p><b>Section:</b> 23.2.4.1 [list.cons], 23.2.4.3 [list.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Hans Bos <b>Date:</b> 2003-06-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#list.cons">issues</a> in [list.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Sections 23.2.4.1 [list.cons] and 23.2.4.3 [list.modifiers] list
-comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
-stack. Only the semantics for queue::operator== (23.2.4.1 [list.cons] par2) and queue::operator&lt; (23.2.4.1 [list.cons]
-par3) are defined.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Add the following new paragraphs after 23.2.4.1 [list.cons]
- paragraph 3:</p>
-
-<blockquote>
-
-<pre> operator!=
-</pre>
-<p>Returns: <tt>x.c != y.c</tt></p>
-
-<pre> operator&gt;
-</pre>
-<p>Returns: <tt>x.c &gt; y.c</tt></p>
-
-<pre> operator&lt;=
-</pre>
-<p>Returns: <tt>x.c &lt;= y.c</tt></p>
-
-<pre> operator&gt;=
-</pre>
-<p>Returns: <tt>x.c &gt;= y.c</tt></p>
-
-</blockquote>
-
-<p>Add the following paragraphs at the end of 23.2.4.3 [list.modifiers]:</p>
-
-<blockquote>
-
-<pre> operator==
-</pre>
-<p>Returns: <tt>x.c == y.c</tt></p>
-
-<pre> operator&lt;
-</pre>
-<p>Returns: <tt>x.c &lt; y.c</tt></p>
-
-<pre> operator!=
-</pre>
-<p>Returns: <tt>x.c != y.c</tt></p>
-
-<pre> operator&gt;
-</pre>
-<p>Returns: <tt>x.c &gt; y.c</tt></p>
-
-<pre> operator&lt;=
-</pre>
-<p>Returns: <tt>x.c &lt;= y.c</tt></p>
-
-<pre> operator&gt;=
-</pre>
-<p>Returns: <tt>x.c &gt;= y.c</tt></p>
-
-</blockquote>
-
-
-<p><i>[Kona: Matt provided wording.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>There isn't any real doubt about what these operators are
-supposed to do, but we ought to spell it out.</p>
-
-
-
-
-
-<hr>
-<h3><a name="411"></a>411. Wrong names of set member functions</h3>
-<p><b>Section:</b> 25.3.5 [alg.set.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Frey <b>Date:</b> 2003-07-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.set.operations">issues</a> in [alg.set.operations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-25.3.5 [alg.set.operations] paragraph 1 reads:
-"The semantics of the set operations are generalized to multisets in a
-standard way by defining union() to contain the maximum number of
-occurrences of every element, intersection() to contain the minimum, and
-so on."
-</p>
-
-<p>
-This is wrong. The name of the functions are set_union() and
-set_intersection(), not union() and intersection().
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change that sentence to use the correct names.</p>
-
-
-
-
-
-<hr>
-<h3><a name="412"></a>412. Typo in 27.4.4.3</h3>
-<p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-07-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#429">429</a></p>
-<p><b>Discussion:</b></p>
-<p>
-The Effects clause in 27.4.4.3 [iostate.flags] paragraph 5 says that the
-function only throws if the respective bits are already set prior to
-the function call. That's obviously not the intent. The typo ought to
-be corrected and the text reworded as: "If (<i>state</i> &amp;
-exceptions()) == 0, returns. ..."
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.4.4.3 [iostate.flags] paragraph 5, replace "If (rdstate() &amp;
-exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
-&amp; exceptions()) == 0".
-</p>
-
-<p><i>[Kona: the original proposed resolution wasn't quite right. We
- really do mean rdstate(); the ambiguity is that the wording in the
- standard doesn't make it clear whether we mean rdstate() before
- setting the new state, or rdsate() after setting it. We intend the
- latter, of course. Post-Kona: Martin provided wording.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="413"></a>413. Proposed resolution to LDR#64 still wrong</h3>
-<p><b>Section:</b> 27.6.1.2.3 [istream::extractors] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2003-07-13</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream::extractors">issues</a> in [istream::extractors].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The second sentence of the proposed resolution says:
-</p>
-
-<p>
-"If it inserted no characters because it caught an exception thrown
-while extracting characters from sb and ..."
-</p>
-
-<p>
-However, we are not extracting from sb, but extracting from the
-basic_istream (*this) and inserting into sb. I can't really tell if
-"extracting" or "sb" is a typo.
-</p>
-
-<p><i>[
-Sydney: Definitely a real issue. We are, indeed, extracting characters
-from an istream and not from sb. The problem was there in the FDIS and
-wasn't fixed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>. Probably what was intended was
-to have *this instead of sb. We're talking about the exception flag
-state of a basic_istream object, and there's only one basic_istream
-object in this discussion, so that would be a consistent
-interpretation. (But we need to be careful: the exception policy of
-this member function must be consistent with that of other
-extractors.) PJP will provide wording.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the sentence from:</p>
-
-<blockquote><p>
-If it inserted no characters because it caught an exception thrown
-while extracting characters from sb and failbit is on in exceptions(),
-then the caught exception is rethrown.
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
-If it inserted no characters because it caught an exception thrown
-while extracting characters from *this and failbit is on in exceptions(),
-then the caught exception is rethrown.
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="414"></a>414. Which iterators are invalidated by v.erase()?</h3>
-<p><b>Section:</b> 23.2.6.4 [vector.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2003-08-19</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Consider the following code fragment:
-</p>
-<blockquote>
-<pre>int A[8] = { 1,3,5,7,9,8,4,2 };
-std::vector&lt;int&gt; v(A, A+8);
-
-std::vector&lt;int&gt;::iterator i1 = v.begin() + 3;
-std::vector&lt;int&gt;::iterator i2 = v.begin() + 4;
-v.erase(i1);
-</pre>
-</blockquote>
-
-<p>
-Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
-both, or neither?
-</p>
-
-<p>
-On all existing implementations that I know of, the status of i1 and
-i2 is the same: both of them will be iterators that point to some
-elements of the vector (albeit not the same elements they did
-before). You won't get a crash if you use them. Depending on
-exactly what you mean by "invalidate", you might say that neither one
-has been invalidated because they still point to <i>something</i>,
-or you might say that both have been invalidated because in both
-cases the elements they point to have been changed out from under the
-iterator.
-</p>
-
-<p>
-The standard doesn't say either of those things. It says that erase
-invalidates all iterators and references "after the point of the
-erase". This doesn't include i1, since it's at the point of the
-erase instead of after it. I can't think of any sensible definition
-of invalidation by which one can say that i2 is invalidated but i1
-isn't.
-</p>
-
-<p>
-(This issue is important if you try to reason about iterator validity
-based only on the guarantees in the standard, rather than reasoning
-from typical implementation techniques. Strict debugging modes,
-which some programmers find useful, do not use typical implementation
-techniques.)
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 23.2.6.4 [vector.modifiers] paragraph 3, change "Invalidates all the
-iterators and references after the point of the erase" to
-"Invalidates iterators and references at or after the point of the
-erase".
-</p>
-
-
-<p><b>Rationale:</b></p>
-<p>I believe this was essentially a typographical error, and that it
- was taken for granted that erasing an element invalidates iterators
- that point to it. The effects clause in question treats iterators
- and references in parallel, and it would seem counterintuitive to
- say that a reference to an erased value remains valid.</p>
-
-
-
-
-
-<hr>
-<h3><a name="415"></a>415. behavior of std::ws</h3>
-<p><b>Section:</b> 27.6.1.4 [istream.manip] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-According to 27.6.1.4, the ws() manipulator is not required to construct
-the sentry object. The manipulator is also not a member function so the
-text in 27.6.1, p1 through 4 that describes the exception policy for
-istream member functions does not apply. That seems inconsistent with
-the rest of extractors and all the other input functions (i.e., ws will
-not cause a tied stream to be flushed before extraction, it doesn't check
-the stream's exceptions or catch exceptions thrown during input, and it
-doesn't affect the stream's gcount).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to 27.6.1.4 [istream.manip], immediately before the first sentence
-of paragraph 1, the following text:
-</p>
-
- <blockquote><p>
- Behaves as an unformatted input function (as described in
- 27.6.1.3, paragraph 1), except that it does not count the number
- of characters extracted and does not affect the value returned by
- subsequent calls to is.gcount(). After constructing a sentry
- object...
- </p></blockquote>
-
-<p><i>[Post-Kona: Martin provided wording]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="416"></a>416. definitions of XXX_MIN and XXX_MAX macros in climits</h3>
-<p><b>Section:</b> 18.2.2 [c.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-Given two overloads of the function foo(), one taking an argument of type
-int and the other taking a long, which one will the call foo(LONG_MAX)
-resolve to? The expected answer should be foo(long), but whether that
-is true depends on the #defintion of the LONG_MAX macro, specifically
-its type. This issue is about the fact that the type of these macros
-is not actually required to be the same as the the type each respective
-limit.
-<br>
-
-Section 18.2.2 of the C++ Standard does not specify the exact types of
-the XXX_MIN and XXX_MAX macros #defined in the &lt;climits&gt; and &lt;limits.h&gt;
-headers such as INT_MAX and LONG_MAX and instead defers to the C standard.
-<br>
-
-Section 5.2.4.2.1, p1 of the C standard specifies that "The values [of
-these constants] shall be replaced by constant expressions suitable for use
-in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX,
-the following shall be replaced by expressions that have the same type as
-would an expression that is an object of the corresponding type converted
-according to the integer promotions."
-<br>
-
-The "corresponding type converted according to the integer promotions" for
-LONG_MAX is, according to 6.4.4.1, p5 of the C standard, the type of long
-converted to the first of the following set of types that can represent it:
-int, long int, long long int. So on an implementation where (sizeof(long)
-== sizeof(int)) this type is actually int, while on an implementation where
-(sizeof(long) &gt; sizeof(int)) holds this type will be long.
-<br>
-
-This is not an issue in C since the type of the macro cannot be detected
-by any conforming C program, but it presents a portability problem in C++
-where the actual type is easily detectable by overload resolution.
-
- </p>
-<p><i>[Kona: the LWG does not believe this is a defect. The C macro
- definitions are what they are; we've got a better
- mechanism, <tt>std::numeric_limits</tt>, that is specified more
- precisely than the C limit macros. At most we should add a
- nonnormative note recommending that users who care about the exact
- types of limit quantities should use &lt;limits&gt; instead of
- &lt;climits&gt;.]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 18.2.2 [c.limits], paragraph 2:
-</p>
-
-<blockquote><p>
--2- The contents are the same as the Standard C library header <tt>&lt;limits.h&gt;</tt>.
-<ins>[<i>Note:</i> The types of the macros in <tt>&lt;climits&gt;</tt> are not guaranteed
-to match the type to which they refer.<i>--end note</i>]</ins>
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="420"></a>420. is std::FILE a complete type?</h3>
-<p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-7.19.1, p2, of C99 requires that the FILE type only be declared in
-&lt;stdio.h&gt;. None of the (implementation-defined) members of the
-struct is mentioned anywhere for obvious reasons.
-</p>
-
-<p>
-C++ says in 27.8.1, p2 that FILE is a type that's defined in &lt;cstdio&gt;. Is
-it really the intent that FILE be a complete type or is an implementation
-allowed to just declare it without providing a full definition?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In the first sentence of 27.8.1 [fstreams] paragraph 2, change
- "defined" to "declared".</p>
-
-
-<p><b>Rationale:</b></p>
-<p>We don't want to impose any restrictions beyond what the C standard
- already says. We don't want to make anything implementation defined,
- because that imposes new requirements in implementations.</p>
-
-
-
-
-
-<hr>
-<h3><a name="422"></a>422. explicit specializations of member functions of class templates</h3>
-<p><b>Section:</b> 17.4.3.2 [reserved.names] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It has been suggested that 17.4.3.1, p1 may or may not allow programs to
-explicitly specialize members of standard templates on user-defined types.
-The answer to the question might have an impact where library requirements
-are given using the "as if" rule. I.e., if programs are allowed to specialize
-member functions they will be able to detect an implementation's strict
-conformance to Effects clauses that describe the behavior of the function
-in terms of the other member function (the one explicitly specialized by
-the program) by relying on the "as if" rule.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
- Add the following sentence to 17.4.3.2 [reserved.names], p1:
-</p>
-
-<blockquote><p>
-It is undefined for a C++ program to add declarations or definitions to
-namespace std or namespaces within namespace <tt>std</tt> unless otherwise specified. A
-program may add template specializations for any standard library template to
-namespace <tt>std</tt>. Such a specialization (complete or partial) of a standard library
-template results in undefined behavior unless the declaration depends on a
-user-defined type of external linkage and unless the specialization meets the
-standard library requirements for the original template.<sup>168)</sup>
-<ins>A program has undefined behavior if it declares</ins>
-</p>
-<ul>
-<li><ins>an explicit specialization of any member function of a standard
- library class template, or</ins></li>
-<li><ins>an explicit specialization of any member function template of a
- standard library class or class template, or</ins></li>
-<li><ins>an explicit or partial specialization of any member class
- template of a standard library class or class template.</ins></li>
-</ul>
-<p>
-A program may explicitly instantiate any templates in the standard library only
-if the declaration depends on the name of a user-defined type of external
-linkage and the instantiation meets the standard library requirements for the
-original template.
-</p></blockquote>
-
-<p><i>[Kona: straw poll was 6-1 that user programs should not be
- allowed to specialize individual member functions of standard
- library class templates, and that doing so invokes undefined
- behavior. Post-Kona: Martin provided wording.]</i></p>
-
-
-<p><i>[Sydney: The LWG agrees that the standard shouldn't permit users
-to specialize individual member functions unless they specialize the
-whole class, but we're not sure these words say what we want them to;
-they could be read as prohibiting the specialization of any standard
-library class templates. We need to consult with CWG to make sure we
-use the right wording.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="425"></a>425. return value of std::get_temporary_buffer</h3>
-<p><b>Section:</b> 20.7.8 [temporary.buffer] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The standard is not clear about the requirements on the value returned from
-a call to get_temporary_buffer(0). In particular, it fails to specify whether
-the call should return a distinct pointer each time it is called (like
-operator new), or whether the value is unspecified (as if returned by
-malloc). The standard also fails to mention what the required behavior
-is when the argument is less than 0.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 20.5.3 [meta.help] paragraph 2 from "...or a pair of 0
-values if no storage can be obtained" to "...or a pair of 0 values if
-no storage can be obtained or if <i>n</i> &lt;= 0."</p>
-<p><i>[Kona: Matt provided wording]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="426"></a>426. search_n(), fill_n(), and generate_n() with negative n</h3>
-<p><b>Section:</b> 25.1.12 [alg.search], 25.2.6 [alg.fill], 25.2.7 [alg.generate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.search">issues</a> in [alg.search].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The complexity requirements for these function templates are incorrect
-(or don't even make sense) for negative n:</p>
-
-<p>25.1.9, p7 (search_n):
-<br>
-Complexity: At most (last1 - first1) * count applications
-of the corresponding predicate.</p>
-
-<p>25.2.5, p3 (fill_n):
-<br>
-Complexity: Exactly last - first (or n) assignments.</p>
-
-<p>25.2.6, p3 (generate_n):
-<br>
-Complexity: Exactly last - first (or n) assignments.</p>
-
-<p>
-In addition, the Requirements or the Effects clauses for the latter two
-templates don't say anything about the behavior when n is negative.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 25.1.9, p7 to</p>
-
-<blockquote><p>
-Complexity: At most (last1 - first1) * count applications
-of the corresponding predicate if count is positive,
-or 0 otherwise.
-</p></blockquote>
-
-<p>Change 25.2.5, p2 to</p>
-<blockquote><p>
-Effects: Assigns value through all the iterators in the range [first,
-last), or [first, first + n) if n is positive, none otherwise.
-</p></blockquote>
-
-<p>Change 25.2.5, p3 to:</p>
-<blockquote><p>
-Complexity: Exactly last - first (or n if n is positive,
-or 0 otherwise) assignments.
-</p></blockquote>
-
-<p>
-Change 25.2.6, p1
-to (notice the correction for the misspelled "through"):
-</p>
-<blockquote><p>
-Effects: Invokes the function object genand assigns the return
-value of gen through all the iterators in the range [first, last),
-or [first, first + n) if n is positive, or [first, first)
-otherwise.
-</p></blockquote>
-
-<p>Change 25.2.6, p3 to:</p>
-<blockquote><p>
-Complexity: Exactly last - first (or n if n is positive,
-or 0 otherwise) assignments.
-</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>Informally, we want to say that whenever we see a negative number
- we treat it the same as if it were zero. We believe the above
- changes do that (although they may not be the minimal way of saying
- so). The LWG considered and rejected the alternative of saying that
- negative numbers are undefined behavior.</p>
-
-
-
-
-
-<hr>
-<h3><a name="428"></a>428. string::erase(iterator) validity</h3>
-<p><b>Section:</b> 21.3.6.5 [string::erase] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-09-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::erase">issues</a> in [string::erase].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
-that q must be a valid dereferenceable iterator into the sequence a.
-</p>
-
-<p>
-However, 21.3.5.5, p5 describing string::erase(p) only requires that
-p be a valid iterator.
-</p>
-
-<p>
-This may be interepreted as a relaxation of the general requirement,
-which is most likely not the intent.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Remove 21.3.6.5 [string::erase] paragraph 5.</p>
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG considered two options: changing the string requirements to
- match the general container requirements, or just removing the
- erroneous string requirements altogether. The LWG chose the latter
- option, on the grounds that duplicating text always risks the
- possibility that it might be duplicated incorrectly.</p>
-
-
-
-
-
-<hr>
-<h3><a name="432"></a>432. stringbuf::overflow() makes only one write position available</h3>
-<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Christian W Brock <b>Date:</b> 2003-09-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>27.7.1.3 par 8 says:</p>
-<blockquote><p>
-Notes: The function can make a write position available only if
- ( mode &amp; ios_base::out) != 0. To make a write position
- available, the function reallocates (or initially allocates) an
- array object with a sufficient number of elements to hold the
- current array object (if any), plus one additional write position.
- If ( mode &amp; ios_base::in) != 0, the function alters the read end
- pointer egptr() to point just past the new write position (as
- does the write end pointer epptr()).
-</p></blockquote>
-
-<p>
-The sentences "plus one additional write position." and especially
- "(as does the write end pointer epptr())" COULD by interpreted
- (and is interpreted by at least my library vendor) as:
-</p>
-
-<blockquote><p>
- post-condition: epptr() == pptr()+1
-</p></blockquote>
-
-<p>
-This WOULD force sputc() to call the virtual overflow() each time.
-</p>
-
-<p>The proposed change also affects Defect Report 169.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>27.7.1.1/2 Change:</p>
-
-<blockquote><p>
-2- Notes: The function allocates no array object.
-</p></blockquote>
-
-<p>
-to:
-</p>
-
-<blockquote><p>
-2- Postcondition: str() == "".
-</p></blockquote>
-
-<p>
-27.7.1.1/3 Change:
-</p>
-
-<blockquote>
-<p>
--3- Effects: Constructs an object of class basic_stringbuf,
-initializing the base class with basic_streambuf()
-(lib.streambuf.cons), and initializing mode with which . Then copies
-the content of str into the basic_stringbuf underlying character
-sequence and initializes the input and output sequences according to
-which. If which &amp; ios_base::out is true, initializes the output
-sequence with the underlying sequence. If which &amp; ios_base::in is
-true, initializes the input sequence with the underlying sequence.
-</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-<p>
--3- Effects: Constructs an object of class basic_stringbuf,
-initializing the base class with basic_streambuf()
-(lib.streambuf.cons), and initializing mode with which. Then copies
-the content of str into the basic_stringbuf underlying character
-sequence. If which &amp; ios_base::out is true, initializes the output
-sequence such that pbase() points to the first underlying character,
-epptr() points one past the last underlying character, and if (which &amp;
-ios_base::ate) is true, pptr() is set equal to
-epptr() else pptr() is set equal to pbase(). If which &amp; ios_base::in
-is true, initializes the input sequence such that eback() and gptr()
-point to the first underlying character and egptr() points one past
-the last underlying character.
-</p>
-</blockquote>
-
-<p>27.7.1.2/1 Change:</p>
-
-<blockquote>
-<p>
--1- Returns: A basic_string object whose content is equal to the
-basic_stringbuf underlying character sequence. If the buffer is only
-created in input mode, the underlying character sequence is equal to
-the input sequence; otherwise, it is equal to the output sequence. In
-case of an empty underlying character sequence, the function returns
-basic_string&lt;charT,traits,Allocator&gt;().
-</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-<p>
--1- Returns: A basic_string object whose content is equal to the
-basic_stringbuf underlying character sequence. If the basic_stringbuf
-was created only in input mode, the resultant basic_string contains
-the character sequence in the range [eback(), egptr()). If the
-basic_stringbuf was created with (which &amp; ios_base::out) being true
-then the resultant basic_string contains the character sequence in the
-range [pbase(), high_mark) where high_mark represents the position one
-past the highest initialized character in the buffer. Characters can
-be initialized either through writing to the stream, or by
-constructing the basic_stringbuf with a basic_string, or by calling
-the str(basic_string) member function. In the case of calling the
-str(basic_string) member function, all characters initialized prior to
-the call are now considered uninitialized (except for those
-characters re-initialized by the new basic_string). Otherwise the
-basic_stringbuf has been created in neither input nor output mode and
-a zero length basic_string is returned.
-</p>
-</blockquote>
-
-<p>
-27.7.1.2/2 Change:
-</p>
-
-<blockquote>
-<p>
--2- Effects: If the basic_stringbuf's underlying character sequence is
-not empty, deallocates it. Then copies the content of s into the
-basic_stringbuf underlying character sequence and initializes the
-input and output sequences according to the mode stored when creating
-the basic_stringbuf object. If (mode&amp;ios_base::out) is true, then
-initializes the output sequence with the underlying sequence. If
-(mode&amp;ios_base::in) is true, then initializes the input sequence with
-the underlying sequence.
-</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-<p>
--2- Effects: Copies the content of s into the basic_stringbuf
-underlying character sequence. If mode &amp; ios_base::out is true,
-initializes the output sequence such that pbase() points to the first
-underlying character, epptr() points one past the last underlying
-character, and if (mode &amp; ios_base::ate) is true,
-pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
-mode &amp; ios_base::in is true, initializes the input sequence such that
-eback() and gptr() point to the first underlying character and egptr()
-points one past the last underlying character.
-</p>
-</blockquote>
-
-<p>Remove 27.2.1.2/3. (Same rationale as issue 238: incorrect and unnecessary.)</p>
-
-<p>27.7.1.3/1 Change:</p>
-
-<blockquote>
-<p>
-1- Returns: If the input sequence has a read position available,
-returns traits::to_int_type(*gptr()). Otherwise, returns
-traits::eof().
-</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-<p>
-1- Returns: If the input sequence has a read position available,
-returns traits::to_int_type(*gptr()). Otherwise, returns
-traits::eof(). Any character in the underlying buffer which has been
-initialized is considered to be part of the input sequence.
-</p>
-</blockquote>
-
-<p>27.7.1.3/9 Change:</p>
-
-<blockquote>
-<p>
--9- Notes: The function can make a write position available only if (
-mode &amp; ios_base::out) != 0. To make a write position available, the
-function reallocates (or initially allocates) an array object with a
-sufficient number of elements to hold the current array object (if
-any), plus one additional write position. If ( mode &amp; ios_base::in) !=
-0, the function alters the read end pointer egptr() to point just past
-the new write position (as does the write end pointer epptr()).
-</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-<p>
--9- The function can make a write position available only if ( mode &amp;
-ios_base::out) != 0. To make a write position available, the function
-reallocates (or initially allocates) an array object with a sufficient
-number of elements to hold the current array object (if any), plus one
-additional write position. If ( mode &amp; ios_base::in) != 0, the
-function alters the read end pointer egptr() to point just past the
-new write position.
-</p>
-</blockquote>
-
-<p>27.7.1.3/12 Change:</p>
-
-<blockquote>
-<p>
--12- _ If (newoff + off) &lt; 0, or (xend - xbeg) &lt; (newoff + off), the
-positioning operation fails. Otherwise, the function assigns xbeg +
-newoff + off to the next pointer xnext .
-</p>
-</blockquote>
-
-<p>to:</p>
-
-<blockquote>
-<p>
--12- _ If (newoff + off) &lt; 0, or if (newoff + off) refers to an
-uninitialized character (as defined in 27.7.1.3 [stringbuf.members]
-paragraph 1), the positioning operation fails. Otherwise, the function
-assigns xbeg + newoff + off to the next pointer xnext .
-</p>
-</blockquote>
-
-<p><i>[post-Kona: Howard provided wording. At Kona the LWG agreed that
- something along these lines was a good idea, but the original
- proposed resolution didn't say enough about the effect of various
- member functions on the underlying character sequences.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The current basic_stringbuf description is over-constrained in such
-a way as to prohibit vendors from making this the high-performance
-in-memory stream it was meant to be. The fundamental problem is that
-the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
-observable from a derived client, and the current description
-restricts the range [pbase(), epptr()) from being grown geometrically.
-This change allows, but does not require, geometric growth of this
-range.</p>
-
-<p>Backwards compatibility issues: These changes will break code that
-derives from basic_stringbuf, observes epptr(), and depends upon
-[pbase(), epptr()) growing by one character on each call to overflow()
-(i.e. test suites). Otherwise there are no backwards compatibility
-issues.</p>
-
-<p>27.7.1.1/2: The non-normative note is non-binding, and if it were
-binding, would be over specification. The recommended change focuses
-on the important observable fact.</p>
-
-<p>27.7.1.1/3: This change does two things: 1. It describes exactly
-what must happen in terms of the sequences. The terms "input
-sequence" and "output sequence" are not well defined. 2. It
-introduces a common extension: open with app or ate mode. I concur
-with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
-
-<p>27.7.1.2/1: This change is the crux of the efficiency issue. The
-resultant basic_string is not dependent upon epptr(), and thus
-implementors are free to grow the underlying buffer geometrically
-during overflow() *and* place epptr() at the end of that buffer.</p>
-
-<p>27.7.1.2/2: Made consistent with the proposed 27.7.1.1/3.</p>
-
-<p>27.7.1.3/1: Clarifies that characters written to the stream beyond
-the initially specified string are available for reading in an i/o
-basic_streambuf.</p>
-
-<p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
-trailing parenthetical comment concerning epptr().</p>
-
-<p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
-longer allowable since [pbase(), epptr()) may now contain
-uninitialized characters. Positioning is only allowable over the
-initialized range.</p>
-
-
-
-
-
-<hr>
-<h3><a name="434"></a>434. bitset::to_string() hard to use</h3>
-<p><b>Section:</b> 23.3.5.2 [bitset.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.members">issues</a> in [bitset.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It has been pointed out a number of times that the bitset to_string() member
-function template is tedious to use since callers must explicitly specify the
-entire template argument list (3 arguments). At least two implementations
-provide a number of overloads of this template to make it easier to use.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In order to allow callers to specify no template arguments at all, just the
-first one (charT), or the first 2 (charT and traits), in addition to all
-three template arguments, add the following three overloads to both the
-interface (declarations only) of the class template bitset as well as to
-section 23.3.5.2, immediately after p34, the Returns clause of the existing
-to_string() member function template:</p>
-
-<pre> template &lt;class charT, class traits&gt;
- basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
- to_string () const;
-
- -34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().
-
- template &lt;class charT&gt;
- basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
- to_string () const;
-
- -34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().
-
- basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
- to_string () const;
-
- -34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
-</pre>
-
-<p><i>[Kona: the LWG agrees that this is an improvement over the
- status quo. Dietmar thought about an alternative using a proxy
- object but now believes that the proposed resolution above is the
- right choice.
-]</i></p>
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="435"></a>435. bug in DR 25</h3>
-<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-It has been pointed out that the proposed resolution in DR 25 may not be
-quite up to snuff: <br>
-http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
-http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
-</p>
-
-<p>
-It looks like Petur is right. The complete corrected text is copied below.
-I think we may have have been confused by the reference to 22.2.2.2.2 and
-the subsequent description of `n' which actually talks about the second
-argument to sputn(), not about the number of fill characters to pad with.
-</p>
-
-<p>
-So the question is: was the original text correct? If the intent was to
-follow classic iostreams then it most likely wasn't, since setting width()
-to less than the length of the string doesn't truncate it on output. This
-is also the behavior of most implementations (except for SGI's standard
-iostreams where the operator does truncate).
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the text in 21.3.7.9, p4 from</p>
- <blockquote><p>
- If bool(k) is true, inserts characters as if by calling
- os.rdbuf()-&gt;sputn(str.data(), n), padding as described in stage 3
- of lib.facet.num.put.virtuals, where n is the larger of os.width()
- and str.size();
- </p></blockquote>
-<p>to</p>
- <blockquote><p>
- If bool(k) is true, determines padding as described in
- lib.facet.num.put.virtuals, and then inserts the resulting
- sequence of characters <tt>seq</tt> as if by calling
- <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
- <tt>os.width()</tt> and <tt>str.size()</tt>;
- </p></blockquote>
-
-<p><i>[Kona: it appears that neither the original wording, DR25, nor the
- proposed resolution, is quite what we want. We want to say that
- the string will be output, padded to os.width() if necessary. We
- don't want to duplicate the padding rules in clause 22, because
- they're complicated, but we need to be careful because they weren't
- quite written with quite this case in mind. We need to say what
- the character sequence is, and then defer to clause 22. Post-Kona:
- Benjamin provided wording.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="436"></a>436. are cv-qualified facet types valid facets?</h3>
-<p><b>Section:</b> 22.1.1.1.2 [locale.facet] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2003-10-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Is "const std::ctype&lt;char&gt;" a valid template argument to has_facet, use_facet,
-and the locale template ctor? And if so, does it designate the same Facet as
-the non-const "std::ctype&lt;char&gt;?" What about "volatile std::ctype&lt;char&gt;?"
-Different implementations behave differently: some fail to compile, others
-accept such types but behave inconsistently.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 22.1.1.1.2, p1 to read:</p>
-
-<p>Template parameters in this clause which are required to be facets
-are those named Facet in declarations. A program that passes a type
-that is not a facet, or a type that refers to volatile-qualified
-facet, as an (explicit or deduced) template parameter to a locale
-function expecting a facet, is ill-formed. A const-qualified facet is
-a valid template argument to any locale function that expects a Facet
-template parameter.</p>
-
-<p><i>[Kona: changed the last sentence from a footnote to normative
-text.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="438"></a>438. Ambiguity in the "do the right thing" clause</h3>
-<p><b>Section:</b> 23.1.3 [sequence.reqmts] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2003-10-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>Section 23.1.3 [sequence.reqmts], paragraphs 9-11, fixed up the problem
-noticed with statements like:</p>
-<pre>vector&lt;int&gt; v(10, 1);
-</pre>
-
-<p>The intent of the above statement was to construct with:</p>
-<pre>vector(size_type, const value_type&amp;);
-</pre>
-
-<p>but early implementations failed to compile as they bound to:</p>
-<pre>template &lt;class InputIterator&gt;
-vector(InputIterator f, InputIterator l);
-</pre>
-<p>instead.</p>
-
-<p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
-member template constructor will have the same effect as:</p>
-<pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
-</pre>
-<p>(and similarly for the other member template functions of sequences).</p>
-
-<p>There is also a note that describes one implementation technique:</p>
-<blockquote><p>
- One way that sequence implementors can satisfy this requirement is to
- specialize the member template for every integral type.
-</p></blockquote>
-
-<p>This might look something like:</p>
-<blockquote>
-<pre>template &lt;class T&gt;
-struct vector
-{
- typedef unsigned size_type;
-
- explicit vector(size_type) {}
- vector(size_type, const T&amp;) {}
-
- template &lt;class I&gt;
- vector(I, I);
-
- // ...
-};
-
-template &lt;class T&gt;
-template &lt;class I&gt;
-vector&lt;T&gt;::vector(I, I) { ... }
-
-template &lt;&gt;
-template &lt;&gt;
-vector&lt;int&gt;::vector(int, int) { ... }
-
-template &lt;&gt;
-template &lt;&gt;
-vector&lt;int&gt;::vector(unsigned, unsigned) { ... }
-
-// ...
-</pre>
-</blockquote>
-
-<p>Label this solution 'A'.</p>
-
-<p>The standard also says:</p>
-<blockquote><p>
- Less cumbersome implementation techniques also exist.
-</p></blockquote>
-<p>
-A popular technique is to not specialize as above, but instead catch
-every call with the member template, detect the type of InputIterator,
-and then redirect to the correct logic. Something like:
-</p>
-<blockquote>
-<pre>template &lt;class T&gt;
-template &lt;class I&gt;
-vector&lt;T&gt;::vector(I f, I l)
-{
- choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
-}
-
-template &lt;class T&gt;
-template &lt;class I&gt;
-vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
-{
- // construct with iterators
-}
-
-template &lt;class T&gt;
-template &lt;class I&gt;
-vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;true&gt;)
-{
- size_type sz = static_cast&lt;size_type&gt;(f);
- value_type v = static_cast&lt;value_type&gt;(l);
- // construct with sz,v
-}
-</pre>
-</blockquote>
-
-<p>Label this solution 'B'.</p>
-
-<p>Both of these solutions solve the case the standard specifically
-mentions:</p>
-<pre>vector&lt;int&gt; v(10, 1); // ok, vector size 10, initialized to 1
-</pre>
-
-<p>
-However, (and here is the problem), the two solutions have different
-behavior in some cases where the value_type of the sequence is not an
-integral type. For example consider:
-</p>
-<blockquote><pre> pair&lt;char, char&gt; p('a', 'b');
- vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt; d('a', 'b');
-</pre></blockquote>
-<p>
-The second line of this snippet is likely an error. Solution A catches
-the error and refuses to compile. The reason is that there is no
-specialization of the member template constructor that looks like:
-</p>
-<pre>template &lt;&gt;
-template &lt;&gt;
-vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
-</pre>
-
-<p>
-So the expression binds to the unspecialized member template
-constructor, and then fails (compile time) because char is not an
-InputIterator.
-</p>
-
-<p>
-Solution B compiles the above example though. 'a' is casted to an
-unsigned integral type and used to size the outer vector. 'b' is
-static casted to the inner vector using it's explicit constructor:
-</p>
-
-<pre>explicit vector(size_type n);
-</pre>
-
-<p>
-and so you end up with a static_cast&lt;size_type&gt;('a') by
-static_cast&lt;size_type&gt;('b') matrix.
-</p>
-
-<p>
-It is certainly possible that this is what the coder intended. But the
-explicit qualifier on the inner vector has been thwarted at any rate.
-</p>
-
-<p>
-The standard is not clear whether the expression:
-</p>
-
-<pre> vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt; d('a', 'b');
-</pre>
-
-<p>
-(and similar expressions) are:
-</p>
-
-<ol>
-<li> undefined behavior.</li>
-<li> illegal and must be rejected.</li>
-<li> legal and must be accepted.</li>
-</ol>
-
-<p>My preference is listed in the order presented.</p>
-
-<p>There are still other techniques for implementing the requirements of
-paragraphs 9-11, namely the "restricted template technique" (e.g.
-enable_if). This technique is the most compact and easy way of coding
-the requirements, and has the behavior of #2 (rejects the above
-expression).
-</p>
-
-<p>
-Choosing 1 would allow all implementation techniques I'm aware of.
-Choosing 2 would allow only solution 'A' and the enable_if technique.
-Choosing 3 would allow only solution 'B'.
-</p>
-
-<p>
-Possible wording for a future standard if we wanted to actively reject
-the expression above would be to change "static_cast" in paragraphs
-9-11 to "implicit_cast" where that is defined by:
-</p>
-
-<blockquote>
-<pre>template &lt;class T, class U&gt;
-inline
-T implicit_cast(const U&amp; u)
-{
- return u;
-}
-</pre>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Replace 23.1.3 [sequence.reqmts] paragraphs 9 - 11 with:</p>
-
-<p>For every sequence defined in this clause and in clause lib.strings:</p>
-
-<ul>
- <li>
- <p>If the constructor</p>
- <pre> template &lt;class InputIterator&gt;
- X(InputIterator f, InputIterator l,
- const allocator_type&amp; a = allocator_type())
- </pre>
- <p>is called with a type InputIterator that does not qualify as
- an input iterator, then the constructor will behave as if the
- overloaded constructor:</p>
- <pre> X(size_type, const value_type&amp; = value_type(),
- const allocator_type&amp; = allocator_type())
- </pre>
- <p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
- </li>
-
- <li>
- <p>If the member functions of the forms:</p>
- <pre> template &lt;class InputIterator&gt; // such as insert()
- rt fx1(iterator p, InputIterator f, InputIterator l);
-
- template &lt;class InputIterator&gt; // such as append(), assign()
- rt fx2(InputIterator f, InputIterator l);
-
- template &lt;class InputIterator&gt; // such as replace()
- rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
- </pre>
- <p>are called with a type InputIterator that does not qualify as
- an input iterator, then these functions will behave as if the
- overloaded member functions:</p>
- <pre> rt fx1(iterator, size_type, const value_type&amp;);
-
- rt fx2(size_type, const value_type&amp;);
-
- rt fx3(iterator, iterator, size_type, const value_type&amp;);
- </pre>
- <p>were called instead, with the same arguments.</p>
- </li>
-</ul>
-
-<p>In the previous paragraph the alternative binding will fail if f
-is not implicitly convertible to X::size_type or if l is not implicitly
-convertible to X::value_type.</p>
-
-<p>
-The extent to which an implementation determines that a type cannot be
-an input iterator is unspecified, except that as a minimum integral
-types shall not qualify as input iterators.
-</p>
-
-
-
-<p><i>[
-Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
-to be accepted, and also agreed that this is surprising behavior. The
-LWG considered several options, including something like
-implicit_cast, which doesn't appear to be quite what we want. We
-considered Howards three options: allow acceptance or rejection,
-require rejection as a compile time error, and require acceptance. By
-straw poll (1-6-1), we chose to require a compile time error.
-Post-Kona: Howard provided wording.
-]</i></p>
-
-
-<p><i>[
-Sydney: The LWG agreed with this general direction, but there was some
-discomfort with the wording in the original proposed resolution.
-Howard submitted new wording, and we will review this again in
-Redmond.
-]</i></p>
-
-
-<p><i>[Redmond: one very small change in wording: the first argument
- is cast to size_t. This fixes the problem of something like
- <tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not
- implicitly convertible to the value type.]</i></p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>The proposed resolution fixes:</p>
-
-<pre> vector&lt;int&gt; v(10, 1);
-</pre>
-
-<p>
-since as integral types 10 and 1 must be disqualified as input
-iterators and therefore the (size,value) constructor is called (as
-if).</p>
-
-<p>The proposed resolution breaks:</p>
-
-<pre> vector&lt;vector&lt;T&gt; &gt; v(10, 1);
-</pre>
-
-<p>
-because the integral type 1 is not *implicitly* convertible to
-vector&lt;T&gt;. The wording above requires a diagnostic.</p>
-
-<p>
-The proposed resolution leaves the behavior of the following code
-unspecified.
-</p>
-
-<pre> struct A
- {
- operator int () const {return 10;}
- };
-
- struct B
- {
- B(A) {}
- };
-
- vector&lt;B&gt; v(A(), A());
-</pre>
-
-<p>
-The implementation may or may not detect that A is not an input
-iterator and employee the (size,value) constructor. Note though that
-in the above example if the B(A) constructor is qualified explicit,
-then the implementation must reject the constructor as A is no longer
-implicitly convertible to B.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="441"></a>441. Is fpos::state const?</h3>
-<p><b>Section:</b> 27.4.3 [fpos] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fpos">issues</a> in [fpos].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In section 27.4.3.1 [fpos.members] fpos&lt;stateT&gt;::state() is declared
-non const, but in section 27.4.3 [fpos] it is declared const.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In section 27.4.3.1 [fpos.members], change the declaration of
-<tt>fpos&lt;stateT&gt;::state()</tt> to const.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="442"></a>442. sentry::operator bool() inconsistent signature</h3>
-<p><b>Section:</b> 27.6.2.4 [ostream::sentry] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-18</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#ostream::sentry">active issues</a> in [ostream::sentry].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream::sentry">issues</a> in [ostream::sentry].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In section 27.6.2.4 [ostream::sentry] paragraph 4, in description part
-basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
-as non const, but in section 27.6.2.3, in synopsis it is declared
-const.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In section 27.6.2.4 [ostream::sentry] paragraph 4, change the declaration
-of <tt>sentry::operator bool()</tt> to const.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="443"></a>443. filebuf::close() inconsistent use of EOF</h3>
-<p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In section 27.8.1.4 [filebuf.members] par6, in effects description of
-basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
-should be overflow(traits::eof()).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change overflow(EOF) to overflow(traits::eof()).
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="444"></a>444. Bad use of casts in fstream</h3>
-<p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Vincent Leloup <b>Date:</b> 2003-11-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>27.8.1.9 [ifstream.members] p1, 27.8.1.13 [ofstream.members] p1,
-27.8.1.17 [fstream.members] p1 seems have same problem as exposed in
-LWG issue
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
- constness. The other two places are stylistic: we could change the
- C-style casts to const_cast. Post-Sydney: Howard provided wording.
-]</i></p>
-
-
-<p>Change 27.8.1.7/1 from:</p>
-<blockquote><p>
- Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
-</p></blockquote>
-
-<p>to:</p>
-<blockquote><p>
- Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
-</p></blockquote>
-
-<p>Change 27.8.1.10/1 from:</p>
-<blockquote><p>
- Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
-</p></blockquote>
-
-<p>to:</p>
-<blockquote><p>
- Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
-</p></blockquote>
-
-<p>Change 27.8.1.13/1 from:</p>
-<blockquote><p>
- Returns: &amp;sb.
-</p></blockquote>
-
-<p>to:</p>
-<blockquote><p>
- Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
-</p></blockquote>
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="445"></a>445. iterator_traits::reference unspecified for some iterator categories</h3>
-<p><b>Section:</b> 24.3.1 [iterator.traits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2003-12-09</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The standard places no restrictions at all on the reference type
-of input, output, or forward iterators (for forward iterators it
-only specifies that *x must be value_type&amp; and doesn't mention
-the reference type). Bidirectional iterators' reference type is
-restricted only by implication, since the base iterator's
-reference type is used as the return type of reverse_iterator's
-operator*, which must be T&amp; in order to be a conforming forward
-iterator.
-</p>
-
-<p>
-Here's what I think we ought to be able to expect from an input
-or forward iterator's reference type R, where a is an iterator
-and V is its value_type
-</p>
-
-<ul>
- <li>
- *a is convertible to R
- </li>
-
- <li>
- R is convertible to V
- </li>
-
- <li>
- static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
- static_cast&lt;V&gt;(*a)
- </li>
-</ul>
-
-<p>A mutable forward iterator ought to satisfy, for x of type V:</p>
- <pre> { R r = *a; r = x; } is equivalent to *a = x;
- </pre>
-
-<p>
-I think these requirements capture existing container iterators
-(including vector&lt;bool&gt;'s), but render istream_iterator invalid;
-its reference type would have to be changed to a constant
-reference.
-</p>
-
-
-<p>
-(Jeremy Siek) During the discussion in Sydney, it was felt that a
-simpler long term solution for this was needed. The solution proposed
-was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
-and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>. Most
-iterators in the Standard Library already meet this requirement. Some
-iterators are output iterators, and do not need to meet the
-requirement, and others are only specified through the general
-iterator requirements (which will change with this resolution). The
-sole case where there is an explicit definition of the reference type
-that will need to change is <tt>istreambuf_iterator</tt> which returns
-<tt>charT</tt> from <tt>operator*</tt> but has a reference type of
-<tt>charT&amp;</tt>. We propose changing the reference type of
-<tt>istreambuf_iterator</tt> to <tt>charT</tt>.
-</p>
-
-<p>The other option for resolving the issue with <tt>pointer</tt>,
- mentioned in the note below, is to remove <tt>pointer</tt>
- altogether. I prefer placing requirements on <tt>pointer</tt> to
- removing it for two reasons. First, <tt>pointer</tt> will become
- useful for implementing iterator adaptors and in particular,
- <tt>reverse_iterator</tt> will become more well defined. Second,
- removing <tt>pointer</tt> is a rather drastic and publicly-visible
- action to take.</p>
-
-<p>The proposed resolution technically enlarges the requirements for
-iterators, which means there are existing iterators (such as
-<tt>istreambuf_iterator</tt>, and potentially some programmer-defined
-iterators) that will no longer meet the requirements. Will this break
-existing code? The scenario in which it would is if an algorithm
-implementation (say in the Standard Library) is changed to rely on
-<tt>iterator_traits::reference</tt>, and then is used with one of the
-iterators that do not have an appropriately defined
-<tt>iterator_traits::reference</tt>.
-</p>
-
-
-<p>The proposed resolution makes one other subtle change. Previously,
-it was required that output iterators have a <tt>difference_type</tt>
-and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
-iterator could not be an output iterator. This is clearly a mistake,
-so I've changed the wording to say that those types may be
-<tt>void</tt>.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>In 24.3.1 [iterator.traits], after:</p>
-
-<blockquote><p>
-be defined as the iterator's difference type, value type and iterator
-category, respectively.
-</p></blockquote>
-
-<p>add</p>
-
-<blockquote><p>
-In addition, the types</p>
-<pre>iterator_traits&lt;Iterator&gt;::reference
-iterator_traits&lt;Iterator&gt;::pointer
-</pre>
-<p>must be defined as the iterator's reference and pointer types, that
-is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
-respectively.</p>
-</blockquote>
-
-<p>In 24.3.1 [iterator.traits], change:</p>
-
-<blockquote><p>
-In the case of an output iterator, the types</p>
-<pre>iterator_traits&lt;Iterator&gt;::difference_type
-iterator_traits&lt;Iterator&gt;::value_type
-</pre>
-<p>are both defined as <tt>void</tt>.</p>
-</blockquote>
-
-<p>to:</p>
-<blockquote><p>
-In the case of an output iterator, the types</p>
-<pre>iterator_traits&lt;Iterator&gt;::difference_type
-iterator_traits&lt;Iterator&gt;::value_type
-iterator_traits&lt;Iterator&gt;::reference
-iterator_traits&lt;Iterator&gt;::pointer
-</pre>
-<p>may be defined as <tt>void</tt>.</p>
-</blockquote>
-
-<p>In 24.5.3 [istreambuf.iterator], change:</p>
-<blockquote>
-<pre>typename traits::off_type, charT*, charT&amp;&gt;
-</pre>
-</blockquote>
-<p>to:</p>
-<blockquote>
-<pre>typename traits::off_type, charT*, charT&gt;
-</pre>
-</blockquote>
-
-<p><i>[
-Redmond: there was concern in Sydney that this might not be the only place
-where things were underspecified and needed to be changed. Jeremy
-reviewed iterators in the standard and confirmed that nothing else
-needed to be changed.
-]</i></p>
-
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="448"></a>448. Random Access Iterators over abstract classes</h3>
-<p><b>Section:</b> 24.1.5 [random.access.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-01-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Table 76, the random access iterator requirement table, says that the
-return type of a[n] must be "convertible to T". When an iterator's
-value_type T is an abstract class, nothing is convertible to T.
-Surely this isn't an intended restriction?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the return type to "convertible to T const&amp;".
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="449"></a>449. Library Issue 306 Goes Too Far</h3>
-<p><b>Section:</b> 18.1 [support.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2004-01-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#support.types">issues</a> in [support.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Original text:</p>
-<blockquote><p>
-The macro offsetof accepts a restricted set of type arguments in this
-International Standard. type shall be a POD structure or a POD union
-(clause 9). The result of applying the offsetof macro to a field that
-is a static data member or a function member is undefined."
-</p></blockquote>
-
-<p>Revised text:</p>
-<blockquote><p>
-"If type is not a POD structure or a POD union the results are undefined."
-</p></blockquote>
-
-<p>
-Looks to me like the revised text should have replaced only the second
-sentence. It doesn't make sense standing alone.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 18.1, paragraph 5, to:</p>
-
-<blockquote><p>
-The macro offsetof accepts a restricted set of type arguments in this
-International Standard. If type is not a POD structure or a POD union
-the results are undefined. The result of applying the offsetof macro
-to a field that is a static data member or a function member is
-undefined."
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="453"></a>453. basic_stringbuf::seekoff need not always fail for an empty stream</h3>
-<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<pre> pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
- ios_base::openmode);
-</pre>
-<p>
-is obliged to fail if nothing has been inserted into the stream. This
-is unnecessary and undesirable. It should be permissible to seek to
-an effective offset of zero.</p>
-
-<p><i>[
- Sydney: Agreed that this is an annoying problem: seeking to zero should be
- legal. Bill will provide wording.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change the sentence from:</p>
-<blockquote><p>
-For a sequence to be positioned, if its next pointer (either
-gptr() or pptr()) is a null pointer, the positioning operation
-fails.
-</p></blockquote>
-
-<p>to:</p>
-
-<blockquote><p>
-For a sequence to be positioned, if its next pointer (either
-gptr() or pptr()) is a null pointer and the new offset newoff
-is nonzero, the positioning operation fails.
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="455"></a>455. cerr::tie() and wcerr::tie() are overspecified</h3>
-<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Both cerr::tie() and wcerr::tie() are obliged to be null at program
-startup. This is overspecification and overkill. It is both traditional
-and useful to tie cerr to cout, to ensure that standard output is drained
-whenever an error message is written. This behavior should at least be
-permitted if not required. Same for wcerr::tie().
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Add to the description of cerr:</p>
-<blockquote><p>
-After the object cerr is initialized, cerr.tie() returns &amp;cout.
-Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
-(lib.basic.ios.cons).
-</p></blockquote>
-
-<p>Add to the description of wcerr:</p>
-
-<blockquote><p>
-After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
-Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
-(lib.basic.ios.cons).
-</p></blockquote>
-
-<p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
- permit, cout and cerr to be tied on startup. Pre-Redmond: Bill will
- provide wording.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="456"></a>456. Traditional C header files are overspecified</h3>
-<p><b>Section:</b> 17.4.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-01-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>The C++ Standard effectively requires that the traditional C headers
-(of the form &lt;xxx.h&gt;) be defined in terms of the newer C++
-headers (of the form &lt;cxxx&gt;). Clauses 17.4.1.2/4 and D.5 combine
-to require that:</p>
-
-<ul>
- <li>Including the header &lt;cxxx&gt; declares a C name in namespace std.</li>
-
- <li> Including the header &lt;xxx.h&gt; declares a C name in namespace std
- (effectively by including &lt;cxxx&gt;), then imports it into the global
- namespace with an individual using declaration.</li>
-</ul>
-
-<p>
-The rules were left in this form despited repeated and heated objections
-from several compiler vendors. The C headers are often beyond the direct
-control of C++ implementors. In some organizations, it's all they can do
-to get a few #ifdef __cplusplus tests added. Third-party library vendors
-can perhaps wrap the C headers. But neither of these approaches supports
-the drastic restructuring required by the C++ Standard. As a result, it is
-still widespread practice to ignore this conformance requirement, nearly
-seven years after the committee last debated this topic. Instead, what is
-often implemented is:
-</p>
-
-<ul>
- <li> Including the header &lt;xxx.h&gt; declares a C name in the
- global namespace.</li>
-
- <li> Including the header &lt;cxxx&gt; declares a C name in the
- global namespace (effectively by including &lt;xxx.h&gt;), then
- imports it into namespace std with an individual using declaration.</li>
-</ul>
-
-<p>
-The practical benefit for implementors with the second approach is that
-they can use existing C library headers, as they are pretty much obliged
-to do. The practical cost for programmers facing a mix of implementations
-is that they have to assume weaker rules:</p>
-
-<ul>
- <li> If you want to assuredly declare a C name in the global
- namespace, include &lt;xxx.h&gt;. You may or may not also get the
- declaration in namespace std.</li>
-
- <li> If you want to assuredly declare a C name in namespace std,
- include &lt;cxxx&gt;. You may or may not also get the declaration in
- the global namespace.</li>
-</ul>
-
-<p>
-There also exists the <i>possibility</i> of subtle differences due to
-Koenig lookup, but there are so few non-builtin types defined in the C
-headers that I've yet to see an example of any real problems in this
-area.
-</p>
-
-<p>
-It is worth observing that the rate at which programmers fall afoul of
-these differences has remained small, at least as measured by newsgroup
-postings and our own bug reports. (By an overwhelming margin, the
-commonest problem is still that programmers include &lt;string&gt; and can't
-understand why the typename string isn't defined -- this a decade after
-the committee invented namespace std, nominally for the benefit of all
-programmers.)
-</p>
-
-<p>
-We should accept the fact that we made a serious mistake and rectify it,
-however belatedly, by explicitly allowing either of the two schemes for
-declaring C names in headers.
-</p>
-
-<p><i>[Sydney: This issue has been debated many times, and will
- certainly have to be discussed in full committee before any action
- can be taken. However, the preliminary sentiment of the LWG was in
- favor of the change. (6 yes, 0 no, 2 abstain) Robert Klarer
- suggests that we might also want to undeprecate the
- C-style <tt>.h</tt> headers.]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to 17.4.1.2 [headers], para. 4:
-</p>
-
-<blockquote><p>
-Except as noted in clauses 18 through 27 and Annex D, the contents of each
-header <i>cname</i> shall be the same as that of the corresponding header
-<i>name.h</i>, as specified in ISO/IEC 9899:1990 Programming Languages C (Clause
-7), or ISO/IEC:1990 Programming Languages-C AMENDMENT 1: C Integrity, (Clause
-7), as appropriate, as if by inclusion. In the C++ Standard Library, however,
-the declarations <del>and definitions</del> (except for names which are defined
-as macros in C) are within namespace scope (3.3.5) of the namespace std.
-<ins>It is unspecified whether these names are first declared within the global
-namespace scope and are then injected into namespace std by explicit
-using-declarations (7.3.3 [namespace.udecl]).</ins>
-</p></blockquote>
-
-<p>
-Change D.5 [depr.c.headers], para. 2-3:
-</p>
-
-<blockquote>
-<p>
--2- Every C header, each of which has a name of the form <i>name.h</i>, behaves
-as if each name placed in the Standard library namespace by the corresponding
-<i>cname</i> header is <del>also</del> placed within the <ins>global</ins>
-namespace scope<ins>.</ins> <del>of the namespace <tt>std</tt> and is followed
-by an explicit <i>using-declaration</i> (7.3.3 [namespace.udecl]).</del>
-<ins>It is unspecified whether these names are first declared or defined within
-namespace scope (3.3.5 [basic.scope.namespace]) of the namespace
-<tt>std</tt> and are then injected into the global namespace scope by explicit
-using-declarations (7.3.3 [namespace.udecl]).</ins>
-</p>
-<p>
--3- [<i>Example:</i> The header <tt>&lt;cstdlib&gt;</tt> <ins>assuredly</ins>
-provides its declarations and definitions within the namespace <tt>std</tt>.
-<ins>It may also provide these names within the global namespace.</ins> The
-header <tt>&lt;stdlib.h&gt;</tt> <del>makes these available also in</del>
-<ins>assuredly provides the same declarations and definitions within</ins> the
-global namespace, much as in the C Standard. <ins>It may also provide these
-names within the namespace <tt>std</tt>.</ins> <i>-- end example</i>]
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="457"></a>457. bitset constructor: incorrect number of initialized bits</h3>
-<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Dag Henriksson <b>Date:</b> 2004-01-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The constructor from unsigned long says it initializes "the first M
-bit positions to the corresponding bit values in val. M is the smaller
-of N and the value CHAR_BIT * sizeof(unsigned long)."
-</p>
-
-<p>
-Object-representation vs. value-representation strikes again. CHAR_BIT *
-sizeof (unsigned long) does not give us the number of bits an unsigned long
-uses to hold the value. Thus, the first M bit position above is not
-guaranteed to have any corresponding bit values in val.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 23.3.5.1 [bitset.cons] paragraph 2, change "M is the smaller of
- N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
- "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
- the value representation (section 3.9 [basic.types]) of <tt>unsigned
- long</tt>."
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="460"></a>460. Default modes missing from basic_fstream member specifications</h3>
-<p><b>Section:</b> 27.8.1 [fstreams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Ben Hutchings <b>Date:</b> 2004-04-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#fstreams">issues</a> in [fstreams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The second parameters of the non-default constructor and of the open
-member function for basic_fstream, named "mode", are optional
-according to the class declaration in 27.8.1.11 [lib.fstream]. The
-specifications of these members in 27.8.1.12 [lib.fstream.cons] and
-27.8.1.13 lib.fstream.members] disagree with this, though the
-constructor declaration has the "explicit" function-specifier implying
-that it is intended to be callable with one argument.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 27.8.1.15 [fstream.cons], change</p>
-<pre> explicit basic_fstream(const char* s, ios_base::openmode mode);
-</pre>
-<p>to</p>
-<pre> explicit basic_fstream(const char* s,
- ios_base::openmode mode = ios_base::in|ios_base::out);
-</pre>
-<p>In 27.8.1.17 [fstream.members], change</p>
-<pre> void open(const char*s, ios_base::openmode mode);
-</pre>
-<p>to</p>
-<pre> void open(const char*s,
- ios_base::openmode mode = ios_base::in|ios_base::out);
-</pre>
-
-
-
-
-
-<hr>
-<h3><a name="461"></a>461. time_get hard or impossible to implement</h3>
-<p><b>Section:</b> 22.2.5.1.2 [locale.time.get.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Bill Plauger <b>Date:</b> 2004-03-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Template time_get currently contains difficult, if not impossible,
-requirements for do_date_order, do_get_time, and do_get_date. All require
-the implementation to scan a field generated by the %x or %X conversion
-specifier in strftime. Yes, do_date_order can always return no_order, but
-that doesn't help the other functions. The problem is that %x can be
-nearly anything, and it can vary widely with locales. It's horribly
-onerous to have to parse "third sunday after Michaelmas in the year of
-our Lord two thousand and three," but that's what we currently ask of
-do_get_date. More practically, it leads some people to think that if
-%x produces 10.2.04, we should know to look for dots as separators. Still
-not easy.
-</p>
-
-<p>
-Note that this is the <i>opposite</i> effect from the intent stated in the
-footnote earlier in this subclause:
-</p>
-
-<blockquote><p>
-"In other words, user confirmation is required for reliable parsing of
-user-entered dates and times, but machine-generated formats can be
-parsed reliably. This allows parsers to be aggressive about interpreting
-user variations on standard formats."
-</p></blockquote>
-
-<p>
-We should give both implementers and users an easier and more reliable
-alternative: provide a (short) list of alternative delimiters and say
-what the default date order is for no_order. For backward compatibility,
-and maximum latitude, we can permit an implementation to parse whatever
-%x or %X generates, but we shouldn't require it.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p><b>In the description:</b></p>
-<pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
- ios_base::iostate&amp; err, tm* t) const;
-</pre>
-
-<p>
-2 Effects: Reads characters starting at suntil it has extracted those
-struct tm members, and remaining format characters, used by
-time_put&lt;&gt;::put to produce the format specified by 'X', or until it
-encounters an error or end of sequence.
-</p>
-
-<p><b>change:</b> 'X'</p>
-
-<p><b>to:</b> "%H:%M:%S"</p>
-
-
-<p>Change</p>
-<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
- ios_base::iostate&amp; err, tm* t) const;
-
-4 Effects: Reads characters starting at s until it has extracted those
-struct tm members, and remaining format characters, used by
-time_put&lt;&gt;::put to produce the format specified by 'x', or until it
-encounters an error.
-</pre>
-
-<p>to</p>
-<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
- ios_base::iostate&amp; err, tm* t) const;
-</pre>
-
-<p>
-4 Effects: Reads characters starting at s until it has extracted those
-struct tm members, and remaining format characters, used by
-time_put&lt;&gt;::put to produce one of the following formats, or until it
-encounters an error. The format depends on the value returned by
-date_order() as follows:
-</p>
-
-<pre> date_order() format
-
- no_order "%m/%d/%y"
- dmy "%d/%m/%y"
- mdy "%m/%d/%y"
- ymd "%y/%m/%d"
- ydm "%y/%d/%m"
-</pre>
-<p>
-An implementation may also accept additional implementation-defined formats.
-</p>
-
-<p><i>[Redmond: agreed that this is a real problem. The solution is
- probably to match C99's parsing rules. Bill provided wording.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="464"></a>464. Suggestion for new member functions in standard containers</h3>
-<p><b>Section:</b> 23.2.6 [vector], 23.3.1 [map] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2004-05-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
-<ol>
-<li> add vector&lt;T&gt;::data() member (const and non-const version)
-semantics: if( empty() ) return 0; else return buffer_;</li>
-<li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
-<i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
-</ol>
-
-<p>Rationale:</p>
-
-<ul>
-<li>To obtain a pointer to the vector's buffer, one must use either
-operator[]() (which can give undefined behavior for empty vectors) or
-at() (which will then throw if the vector is empty). </li>
-<li>tr1::array&lt;T,sz&gt; already has a data() member</li>
-<li>e cannot use operator[]() when T is not DefaultDonstructible</li>
-<li>Neither when the map is const.</li>
-<li>when we want to make sure we don't add an element accidently</li>
-<li>when it should be considered an error if a key is not in the map</li>
-</ul>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 23.2.6 [vector], add the following to the <tt>vector</tt>
- synopsis after "element access" and before "modifiers":</p>
-<pre> // <i>[lib.vector.data] data access</i>
- pointer data();
- const_pointer data() const;
-</pre>
-
-<p>Add a new subsection of 23.2.6 [vector]:</p>
-<blockquote>
-<p>23.2.4.x <tt>vector</tt> data access</p>
-<pre> pointer data();
- const_pointer data() const;
-</pre>
-<p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
- range. For a non-empty vector, data() == &amp;front().</p>
-<p><b>Complexity:</b> Constant time.</p>
-<p><b>Throws:</b> Nothing.</p>
-</blockquote>
-
-<p>In 23.3.1 [map], add the following to the <tt>map</tt>
-synopsis immediately after the line for operator[]:</p>
-<pre> T&amp; at(const key_type&amp; x);
- const T&amp; at(const key_type&amp; x) const;
-</pre>
-
-<p>Add the following to 23.3.1.2 [map.access]:</p>
-<blockquote>
-<pre> T&amp; at(const key_type&amp; x);
- const T&amp; at(const key_type&amp; x) const;
-</pre>
-
-<p><b>Returns:</b> A reference to the element whose key is equivalent
- to x, if such an element is present in the map.</p>
-<p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
-
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>Neither of these additions provides any new functionality but the
- LWG agreed that they are convenient, especially for novices. The
- exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
- was chosen to match <tt>vector::at</tt>.</p>
-
-
-
-
-
-<hr>
-<h3><a name="465"></a>465. Contents of &lt;ciso646&gt;</h3>
-<p><b>Section:</b> 17.4.1.2 [headers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Steve Clamage <b>Date:</b> 2004-06-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#headers">issues</a> in [headers].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>C header &lt;iso646.h&gt; defines macros for some operators, such as
-not_eq for !=.</p>
-
-<p>Section 17.4.1.2 [headers] "Headers" says that except as noted in
-clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
-as the C header &lt;name.h&gt;. In particular, table 12 lists
-&lt;ciso646&gt; as a C++ header.</p>
-
-<p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
-&lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
-contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
-
-<p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
-"Header &lt;iso646.h&gt;" says that the alternative tokens are not
-defined as macros in &lt;ciso646&gt;, but does not mention the contents
-of &lt;iso646.h&gt;.</p>
-
-<p>I don't find any normative text to support C.2.2.2.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
- paragraph 6 (the one about functions must be functions):</p>
-
-<blockquote>
-<p>Identifiers that are keywords or operators in C++ shall not be defined
-as macros in C++ standard library headers.
-[Footnote:In particular, including the standard header &lt;iso646.h&gt;
-or &lt;ciso646&gt; has no effect. </p>
-</blockquote>
-
-<p><i>[post-Redmond: Steve provided wording.]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="467"></a>467. char_traits::lt(), compare(), and memcmp()</h3>
-<p><b>Section:</b> 21.1.3.1 [char.traits.specializations.char] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-Table 37 describes the requirements on Traits::compare() in terms of
-those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
-to yield the same result as operator&lt;(char, char).
-</p>
-
-<p>
-Most, if not all, implementations of char_traits&lt;char&gt;::compare()
-call memcmp() for efficiency. However, the C standard requires both
-memcmp() and strcmp() to interpret characters under comparison as
-unsigned, regardless of the signedness of char. As a result, all
-these char_traits implementations fail to meet the requirement
-imposed by Table 37 on compare() when char is signed.
-</p>
-
-
-<p>Read email thread starting with c++std-lib-13499 for more. </p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-
-<p>Change 21.1.3.1, p6 from</p>
-<blockquote><p>
- The two-argument members assign, eq, and lt are defined identically
- to the built-in operators =, ==, and &lt; respectively.
-</p></blockquote>
-<p>to</p>
-<blockquote><p>
- The two-argument member assign is defined identically to
- the built-in operator =. The two
- argument members eq and lt are defined identically to
- the built-in operators == and &lt; for type unsigned char.
-</p></blockquote>
-
-<p><i>[Redmond: The LWG agreed with this general direction, but we
- also need to change <tt>eq</tt> to be consistent with this change.
- Post-Redmond: Martin provided wording.]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="468"></a>468. unexpected consequences of ios_base::operator void*()</h3>
-<p><b>Section:</b> 27.4.4.3 [iostate.flags] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostate.flags">issues</a> in [iostate.flags].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>The program below is required to compile but when run it typically
-produces unexpected results due to the user-defined conversion from
-std::cout or any object derived from basic_ios to void*.
-</p>
-
-<pre> #include &lt;cassert&gt;
- #include &lt;iostream&gt;
-
- int main ()
- {
- assert (std::cin.tie () == std::cout);
- // calls std::cout.ios::operator void*()
- }
-</pre>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
-conversion operator to some unspecified type that is guaranteed not
-to be convertible to any other type except for bool (a pointer-to-member
-might be one such suitable type). In addition, make it clear that the
-pointer type need not be a pointer to a complete type and when non-null,
-the value need not be valid.
-</p>
-
-<p>Specifically, change in [lib.ios] the signature of</p>
-<pre> operator void*() const;
-</pre>
-<p>to</p>
-<pre> operator unspecified-bool-type() const;
-</pre>
-<p>and change [lib.iostate.flags], p1 from</p>
-<pre> operator void*() const;
-</pre>
-<p>to</p>
-<pre>operator unspecified-bool-type() const;
-
- -1- Returns: if fail() then a value that will evaluate false in a
- boolean context; otherwise a value that will evaluate true in a
- boolean context. The value type returned shall not be
- convertible to int.
-
- -2- [Note: This conversion can be used in contexts where a bool
- is expected (e.g., an if condition); however, implicit
- conversions (e.g., to int) that can occur with bool are not
- allowed, eliminating some sources of user error. One possible
- implementation choice for this type is pointer-to-member. - end
- note]
-</pre>
-
-<p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
-
-<p><i>[Lillehammer: Doug provided revised wording for
- "unspecified-bool-type".]</i></p>
-
-
-
-
-
-
-
-
-<hr>
-<h3><a name="469"></a>469. vector&lt;bool&gt; ill-formed relational operators</h3>
-<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-06-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-The overloads of relational operators for vector&lt;bool&gt; specified
-in [lib.vector.bool] are redundant (they are semantically identical
-to those provided for the vector primary template) and may even be
-diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
-in c++std-lib-13647).
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove all overloads of overloads of relational operators for
-vector&lt;bool&gt; from [lib.vector.bool].
-</p>
-
-
-
-
-<hr>
-<h3><a name="474"></a>474. confusing Footnote 297</h3>
-<p><b>Section:</b> 27.6.2.6.4 [ostream.inserters.character] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2004-07-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.character">issues</a> in [ostream.inserters.character].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-I think Footnote 297 is confused. The paragraph it applies to seems
-quite clear in that widen() is only called if the object is not a char
-stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
-value of widen(c) is otherwise.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-I propose to strike the Footnote.
-</p>
-
-
-
-
-<hr>
-<h3><a name="475"></a>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3>
-<p><b>Section:</b> 25.1.4 [alg.foreach] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 2004-07-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It is not clear whether the function object passed to for_each is allowed to
-modify the elements of the sequence being iterated over.
-</p>
-
-<p>
-for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
-Non-modifying sequence operations". 'Non-modifying sequence operation' is
-never defined.
-</p>
-
-<p>
-25(5) says: "If an algorithm's Effects section says that a value pointed to
-by any iterator passed as an argument is modified, then that algorithm has
-an additional type requirement: The type of that argument shall satisfy the
-requirements of a mutable iterator (24.1)."
-</p>
-
-<p>for_each's Effects section does not mention whether arguments can be
-modified:</p>
-
-<blockquote><p>
- "Effects: Applies f to the result of dereferencing every iterator in the
- range [first, last), starting from first and proceeding to last - 1."
-</p></blockquote>
-
-<p>
-Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
-the sense that neither the algorithms themselves nor the function objects
-passed to the algorithms may modify the sequences or elements in any way.
-This DR affects only for_each.
-</p>
-
-<p>
-We suspect that for_each's classification in "non-modifying sequence
-operations" means that the algorithm itself does not inherently modify the
-sequence or the elements in the sequence, but that the function object
-passed to it may modify the elements it operates on.
-</p>
-
-<p>
-The original STL document by Stepanov and Lee explicitly prohibited the
-function object from modifying its argument.
-The "obvious" implementation of for_each found in several standard library
-implementations, however, does not impose this restriction.
-As a result, we suspect that the use of for_each with function objects that modify
-their arguments is wide-spread.
-If the restriction was reinstated, all such code would become non-conforming.
-Further, none of the other algorithms in the Standard
-could serve the purpose of for_each (transform does not guarantee the order in
-which its function object is called).
-</p>
-
-<p>
-We suggest that the standard be clarified to explicitly allow the function object
-passed to for_each modify its argument.</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add a nonnormative note to the Effects in 25.1.4 [alg.foreach]: If
-the type of 'first' satisfies the requirements of a mutable iterator,
-'f' may apply nonconstant functions through the dereferenced iterators
-passed to it.
-</p>
-
-
-
-<p><b>Rationale:</b></p>
-<p>The LWG believes that nothing in the standard prohibits function
- objects that modify the sequence elements. The problem is that
- for_each is in a secion entitled "nonmutating algorithms", and the
- title may be confusing. A nonnormative note should clarify that.</p>
-
-
-
-
-
-<hr>
-<h3><a name="478"></a>478. Should forward iterator requirements table have a line for r-&gt;m?</h3>
-<p><b>Section:</b> 24.1.3 [forward.iterators] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Dave Abrahams <b>Date:</b> 2004-07-11</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward.iterators">issues</a> in [forward.iterators].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
-<p><b>Discussion:</b></p>
-<p>
-The Forward Iterator requirements table contains the following:
-</p>
-<pre> expression return type operational precondition
- semantics
- ========== ================== =========== ==========================
- a-&gt;m U&amp; if X is mutable, (*a).m pre: (*a).m is well-defined.
- otherwise const U&amp;
-
- r-&gt;m U&amp; (*r).m pre: (*r).m is well-defined.
-</pre>
-
-<p>The second line may be unnecessary. Paragraph 11 of
- [lib.iterator.requirements] says:
-</p>
-
-<blockquote><p>
- In the following sections, a and b denote values of type const X, n
- denotes a value of the difference type Distance, u, tmp, and m
- denote identifiers, r denotes a value of X&amp;, t denotes a value of
- value type T, o denotes a value of some type that is writable to
- the output iterator.
-</p></blockquote>
-
-<p>
-Because operators can be overloaded on an iterator's const-ness, the
-current requirements allow iterators to make many of the operations
-specified using the identifiers a and b invalid for non-const
-iterators.</p>
-
-<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>Remove the "r-&gt;m" line from the Forward Iterator requirements
-table. Change</p>
-<blockquote><p>
- "const X"
-</p></blockquote>
-
-<p> to </p>
-
-<blockquote><p>
- "X or const X"
-</p></blockquote>
-
-<p>in paragraph 11 of [lib.iterator.requirements].</p>
-
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-This is a defect because it constrains an lvalue to returning a modifiable lvalue.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="488"></a>488. rotate throws away useful information</h3>
-<p><b>Section:</b> 25.2.11 [alg.rotate] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2004-11-22</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-rotate takes 3 iterators: first, middle and last which point into a
-sequence, and rearranges the sequence such that the subrange [middle,
-last) is now at the beginning of the sequence and the subrange [first,
-middle) follows. The return type is void.
-</p>
-
-<p>
-In many use cases of rotate, the client needs to know where the
-subrange [first, middle) starts after the rotate is performed. This
-might look like:
-</p>
-<pre> rotate(first, middle, last);
- Iterator i = advance(first, distance(middle, last));
-</pre>
-
-<p>
-Unless the iterators are random access, the computation to find the
-start of the subrange [first, middle) has linear complexity. However,
-it is not difficult for rotate to return this information with
-negligible additional computation expense. So the client could code:
-</p>
-<pre> Iterator i = rotate(first, middle, last);
-</pre>
-
-<p>
-and the resulting program becomes significantly more efficient.
-</p>
-
-<p>
-While the backwards compatibility hit with this change is not zero, it
-is very small (similar to that of lwg <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>), and there is
-a significant benefit to the change.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>In 25 [algorithms] p2, change:</p>
-
-<blockquote><pre> template&lt;class ForwardIterator&gt;
- <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
- ForwardIterator last);
-</pre></blockquote>
-
-<p>In 25.2.11 [alg.rotate], change:</p>
-
-<blockquote><pre> template&lt;class ForwardIterator&gt;
- <del>void</del> <ins>ForwardIterator</ins> rotate(ForwardIterator first, ForwardIterator middle,
- ForwardIterator last);
-</pre></blockquote>
-
-<p>In 25.2.11 [alg.rotate] insert a new paragraph after p1:</p>
-
-<blockquote>
-<p><b>Returns</b>: <tt>first + (last - middle)</tt>.</p>
-</blockquote>
-
-<p><i>[
-The LWG agrees with this idea, but has one quibble: we want to make
-sure not to give the impression that the function "advance" is
-actually called, just that the nth iterator is returned. (Calling
-advance is observable behavior, since users can specialize it for
-their own iterators.) Howard will provide wording.
-]</i></p>
-
-
-<p><i>[Howard provided wording for mid-meeting-mailing Jun. 2005.]</i></p>
-
-
-<p><i>[
-Toronto: moved to Ready.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="495"></a>495. Clause 22 template parameter requirements</h3>
-<p><b>Section:</b> 22 [localization] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2005-01-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#localization">issues</a> in [localization].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>It appears that there are no requirements specified for many of the
-template parameters in clause 22. It looks like this issue has never
-come up, except perhaps for Facet.</p>
-
-<p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
-either, which is the wording that allows requirements on template
-parameters to be identified by name.</p>
-
-<p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
-changed to cover clause 22. A better change, which will cover us in
-the future, would be to say that it applies to all the library
-clauses. Then if a template gets added to any library clause we are
-covered.</p>
-
-<p>charT, InputIterator, and other names with requirements defined
-elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
-But there are a few template arguments names which I don't think have
-requirements given elsewhere:</p>
-
-<ul>
-<li>internT and externT. The fix is to add wording saying that internT
-and externT must meet the same requirements as template arguments
-named charT.</li>
-
-<li>stateT. I'm not sure about this one. There already is some wording,
-but it seems a bit vague.</li>
-
-<li>Intl. [lib.locale.moneypunct.byname] The fix for this one is to
-rename "Intl" to "International". The name is important because other
-text identifies the requirements for the name International but not
-for Intl.</li>
-</ul>
-
-<p><b>Proposed resolution:</b></p>
-<p>Change 17.3.2.1 [type.descriptions], paragraph 1, from:</p>
-<blockquote><p>
-The Requirements subclauses may describe names that are used to
-specify constraints on template arguments.153) These names are used in
-clauses 20, 23, 25, and 26 to describe the types that may be supplied
-as arguments by a C++ program when instantiating template components
-from the library.
-</p></blockquote>
-<p>to:</p>
-<blockquote><p>
-The Requirements subclauses may describe names that are used to
-specify constraints on template arguments.153) These names are used in
-library clauses to describe the types that may be supplied as
-arguments by a C++ program when instantiating template components from
-the library.
-</p></blockquote>
-
-<p>In the front matter of class 22, locales, add:</p>
-<blockquote><p>
-Template parameter types internT and externT shall meet the
-requirements of charT (described in 21 [strings]).
-</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>
- Again, a blanket clause isn't blanket enough. Also, we've got a
- couple of names that we don't have blanket requirement statements
- for. The only issue is what to do about stateT. This wording is
- thin, but probably adequate.</p>
-
-
-
-
-
-<hr>
-<h3><a name="496"></a>496. Illegal use of "T" in vector&lt;bool&gt;</h3>
-<p><b>Section:</b> 23.2.6 [vector] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> richard@ex-parrot.com <b>Date:</b> 2005-02-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector">issues</a> in [vector].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.2.6 [vector],
-the non-template assign() function has the signature</p>
-
-<pre> void assign( size_type n, const T&amp; t );
-</pre>
-
-<p>The type, T, is not defined in this context.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Replace "T" with "value_type".</p>
-
-
-
-
-
-<hr>
-<h3><a name="497"></a>497. meaning of numeric_limits::traps for floating point types</h3>
-<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-03-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
-
-<blockquote>
-<p>static const bool traps;<br>
--59- true if trapping is implemented for the type.204)
-<br>
-Footnote 204: Required by LIA-1.
-</p>
-</blockquote>
-
-<p>It's not clear what is meant by "is implemented" here.</p>
-
-<p>
-In the context of floating point numbers it seems reasonable to expect
-to be able to use traps to determine whether a program can "safely" use
-infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
-without causing a trap (i.e., on UNIX without having to worry about
-getting a signal). When traps is true, I would expect any of the
-operations in section 7 of IEEE 754 to cause a trap (and my program
-to get a SIGFPE). So, for example, on Alpha, I would expect traps
-to be true by default (unless I compiled my program with the -ieee
-option), false by default on most other popular architectures,
-including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
-traps to be explicitly enabled by the program.
-</p>
-
-<p>
-Another possible interpretation of p59 is that traps should be true
-on any implementation that supports traps regardless of whether they
-are enabled by default or not. I don't think such an interpretation
-makes the traps member very useful, even though that is how traps is
-implemented on several platforms. It is also the only way to implement
-traps on platforms that allow programs to enable and disable trapping
-at runtime.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Change p59 to read:</p>
-<blockquote><p>True if, at program startup, there exists a value of the type that
- would cause an arithmetic operation using that value to trap.</p></blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>
- Real issue, since trapping can be turned on and off. Unclear what a
- static query can say about a dynamic issue. The real advice we should
- give users is to use cfenv for these sorts of queries. But this new
- proposed resolution is at least consistent and slightly better than
- nothing.</p>
-
-
-
-
-
-<hr>
-<h3><a name="505"></a>505. Result_type in random distribution requirements</h3>
-<p><b>Section:</b> 26.4.1 [rand.req], TR1 5.1.1 [tr.rand.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req">issues</a> in [rand.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Table 17: Random distribution requirements
-</p>
-<p>
-Row 1 requires that each random distribution provide a nested type "input_type";
-this type denotes the type of the values that the distribution consumes.
-</p>
-<p>
-Inspection of all distributions in [tr.rand.dist] reveals that each distribution
-provides a second typedef ("result_type") that denotes the type of the values the
-distribution produces when called.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-It seems to me that this is also a requirement
-for all distributions and should therefore be indicated as such via a new second
-row to this table 17:
-</p>
-<table border="1" cellpadding="5">
-<tbody><tr><td>X::result_type</td><td>T</td><td>---</td><td>compile-time</td></tr>
-</tbody></table>
-
-<p><i>[
-Berlin: Voted to WP. N1932 adopts the proposed resolution: see Table 5 row 1.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="507"></a>507. Missing requirement for variate_generator::operator()</h3>
-<p><b>Section:</b> 26.4 [rand], TR1 5.1.3 [tr.rand.var] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Paragraph 11 of [tr.rand.var] equires that the member template
-</p>
-<blockquote><pre>template&lt;class T&gt; result_type operator() (T value);
-</pre></blockquote>
-<p>
-return
-</p>
-<blockquote><pre>distribution()(e, value)
-</pre></blockquote>
-<p>
-However, not all distributions have an operator() with a corresponding signature.
-</p>
-
-<p><i>[
-Berlin: As a working group we voted in favor of N1932 which makes this moot:
-variate_generator has been eliminated. Then in full committee we voted to give
-this issue WP status (mistakenly).
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-We therefore recommend that we insert the following precondition before paragraph 11:
-</p>
-<blockquote><p>
-Precondition: <tt>distribution().operator()(e,value)</tt> is well-formed.
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="508"></a>508. Bad parameters for ranlux64_base_01</h3>
-<p><b>Section:</b> 26.4.5 [rand.predef], TR1 5.1.5 [tr.rand.predef] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2005-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.predef">issues</a> in [rand.predef].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The fifth of these engines with predefined parameters, ranlux64_base_01,
-appears to have an unintentional error for which there is a simple correction.
-The two pre-defined subtract_with_carry_01 engines are given as:
-</p>
-<blockquote><pre>typedef subtract_with_carry_01&lt;float, 24, 10, 24&gt; ranlux_base_01;
-typedef subtract_with_carry_01&lt;double, 48, 10, 24&gt; ranlux64_base_01;
-</pre></blockquote>
-<p>
-We demonstrate below that ranlux64_base_01 fails to meet the intent of the
-random number generation proposal, but that the simple correction to
-</p>
-<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
-</pre></blockquote>
-<p>
-does meet the intent of defining well-known good parameterizations.
-</p>
-<p>
-The ranlux64_base_01 engine as presented fails to meet the intent for
-predefined engines, stated in proposal N1398 (section E):
-</p>
-<blockquote><p>
-In order to make good random numbers available to a large number of library
-users, this proposal not only defines generic random-number engines, but also
-provides a number of predefined well-known good parameterizations for those.
-</p></blockquote>
-<p>
-The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
-long period and so meets this criterion. This property makes it suitable for
-use in the excellent discard_block engines defined subsequently. The proof
-of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
-+ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
-as defined in [tr.rand.eng.sub1]).
-</p>
-<p>
-The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
-For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
-explicit factorization would be a challenge). In consequence, while it is
-certainly possible for some seeding states that this engine would have a very
-long period, it is not at all "well-known" that this is the case. The intent
-in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
-use in the physics community. This is isomorphic to the predefined ranlux_base_01,
-but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
-to deliver 48 random bits at a time rather than 24.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-To achieve this intended behavior, the correct template parameteriztion would be:
-</p>
-<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
-</pre></blockquote>
-<p>
-The sequence of mantissa bits delivered by this is isomorphic (treating each
-double as having the bits of two floats) to that delivered by ranlux_base_01.
-</p>
-<p>
-<b>References:</b>
-</p>
-<ol>
-<li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
-<li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
-<li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
-</ol>
-
-<p><i>[
-Berlin: Voted to WP. N1932 adopts the proposed resolution in 26.3.5,
-just above paragraph 5.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="518"></a>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3>
-<p><b>Section:</b> 23.1.5 [unord.req], TR1 6.3.1 [tr.unord.req] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-07-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unord.req">issues</a> in [unord.req].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Issue 371 deals with stability of multiset/multimap under insert and erase
-(i.e. do they preserve the relative order in ranges of equal elements).
-The same issue applies to unordered_multiset and unordered_multimap.
-</p>
-<p><i>[
-Moved to open (from review): There is no resolution.
-]</i></p>
-
-
-<p><i>[
-Toronto: We have a resolution now. Moved to Review. Some concern was noted
-as to whether this conflicted with existing practice or not. An additional
-concern was in specifying (partial) ordering for an unordered container.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Wording for the proposed resolution is taken from the equivalent text for associative containers.
-</p>
-
-<p>
-Change 23.1.5 [unord.req], Unordered associative containers, paragraph 6 to:
-</p>
-
-<blockquote><p>
-An unordered associative container supports <i>unique</i> keys if it may
-contain at most one element for each key. Otherwise, it supports <i>equivalent
-keys</i>. <tt>unordered_set</tt> and <tt>unordered_map</tt> support
-unique keys. <tt>unordered_multiset</tt> and <tt>unordered_multimap</tt>
-support equivalent keys. In containers that support equivalent keys, elements
-with equivalent keys are adjacent to each other. <ins>For
-<tt>unordered_multiset</tt>
-and <tt>unordered_multimap</tt>,<tt> insert</tt> and <tt>erase</tt>
-preserve the relative ordering of equivalent elements.</ins>
-</p></blockquote>
-
-<p>
-Change 23.1.5 [unord.req], Unordered associative containers, paragraph 8 to:
-</p>
-
-<blockquote>
-<p>The elements of an unordered associative container are organized into <i>
-buckets</i>. Keys with the same hash code appear in the same bucket. The number
-of buckets is automatically increased as elements are added to an unordered
-associative container, so that the average number of elements per bucket is kept
-below a bound. Rehashing invalidates iterators, changes ordering between
-elements, and changes which buckets elements appear in, but does not invalidate
-pointers or references to elements. <ins>For <tt>unordered_multiset</tt>
-and <tt>unordered_multimap</tt>, rehashing
-preserves the relative ordering of equivalent elements.</ins></p>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="519"></a>519. Data() undocumented</h3>
-<p><b>Section:</b> 23.2.1 [array], TR1 6.2.2 [tr.array.array] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#array">active issues</a> in [array].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#array">issues</a> in [array].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>array&lt;&gt;::data()</tt> is present in the class synopsis, but not documented.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a new section, after 6.2.2.3:
-</p>
-<blockquote><pre>T* data()
-const T* data() const;
-</pre></blockquote>
-<p>
-<b>Returns:</b> <tt>elems</tt>.
-</p>
-<p>
-Change 6.2.2.4/2 to:
-</p>
-<blockquote><p>
-In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
-of <tt>data()</tt> is unspecified.
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="520"></a>520. Result_of and pointers to data members</h3>
-<p><b>Section:</b> 20.6.11.1 [func.bind], TR1 3.6 [tr.func.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In the original proposal for binders, the return type of bind() when
-called with a pointer to member data as it's callable object was
-defined to be mem_fn(ptr); when Peter Dimov and I unified the
-descriptions of the TR1 function objects we hoisted the descriptions
-of return types into the INVOKE pseudo-function and into result_of.
-Unfortunately, we left pointer to member data out of result_of, so
-bind doesn't have any specified behavior when called with a pointer
-to member data.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p><i>[
-Pete and Peter will provide wording.
-]</i></p>
-
-
-<p>
-In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2:
-</p>
-<ol start="3">
-<li>If <tt>F</tt> is a member data pointer type <tt>R T::*</tt>, <tt>type</tt>
-shall be <tt><i>cv</i> R&amp;</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&amp;</tt>,
-<tt>R</tt> otherwise.</li>
-</ol>
-
-<p><i>[
-Peter provided wording.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="521"></a>521. Garbled requirements for argument_type in reference_wrapper</h3>
-<p><b>Section:</b> 20.6.5 [refwrap], TR1 2.1.2 [tr.util.refwrp.refwrp] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2005-07-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-2.1.2/3, second bullet item currently says that reference_wrapper&lt;T&gt; is
-derived from unary_function&lt;T, R&gt; if T is:
-</p>
-<blockquote><p>
-a pointer to member function type with cv-qualifier cv and no arguments;
-the type T1 is cv T* and R is the return type of the pointer to member function;
-</p></blockquote>
-<p>
-The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
-function. It should be a pointer to the class that T is a pointer to member of.
-Like this:
-</p>
-<blockquote><p>
-a pointer to a member function R T0::f() cv (where cv represents the member
-function's cv-qualifiers); the type T1 is cv T0*
-</p></blockquote>
-<p>
-Similarly, bullet item 2 in 2.1.2/4 should be:
-</p>
-<blockquote><p>
-a pointer to a member function R T0::f(T2) cv (where cv represents the member
-function's cv-qualifiers); the type T1 is cv T0*
-</p></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change bullet item 2 in 2.1.2/3:
-</p>
-
-<blockquote>
-<ul>
-<li>
-a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments;
-the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return
-type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt>
-(where <tt><i>cv</i></tt> represents the member function's cv-qualifiers);
-the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
-</li>
-</ul>
-</blockquote>
-
-<p>
-Change bullet item 2 in 2.1.2/4:
-</p>
-
-<blockquote>
-<ul>
-<li>
-a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument
-of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and
-<tt>R</tt> is the return type of the pointer to member function</del>
-<ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member
-function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
-</li>
-</ul>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="524"></a>524. regex named character classes and case-insensitivity don't mix</h3>
-<p><b>Section:</b> 28 [re] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Eric Niebler <b>Date:</b> 2005-07-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re">issues</a> in [re].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-This defect is also being discussed on the Boost developers list. The
-full discussion can be found here:
-http://lists.boost.org/boost/2005/07/29546.php
-</p>
-<p>
--- Begin original message --
-</p>
-<p>
-Also, I may have found another issue, closely related to the one under
-discussion. It regards case-insensitive matching of named character
-classes. The regex_traits&lt;&gt; provides two functions for working with
-named char classes: lookup_classname and isctype. To match a char class
-such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
-bitmask. Later, you pass a char and the bitmask to isctype and get a
-bool yes/no answer.
-</p>
-<p>
-But how does case-insensitivity work in this scenario? Suppose we're
-doing a case-insensitive match on [[:lower:]]. It should behave as if it
-were [[:lower:][:upper:]], right? But there doesn't seem to be enough
-smarts in the regex_traits interface to do this.
-</p>
-<p>
-Imagine I write a traits class which recognizes [[:fubar:]], and the
-"fubar" char class happens to be case-sensitive. How is the regex engine
-to know that? And how should it do a case-insensitive match of a
-character against the [[:fubar:]] char class? John, can you confirm this
-is a legitimate problem?
-</p>
-<p>
-I see two options:
-</p>
-<p>
-1) Add a bool icase parameter to lookup_classname. Then,
-lookup_classname( "upper", true ) will know to return lower|upper
-instead of just upper.
-</p>
-<p>
-2) Add a isctype_nocase function
-</p>
-<p>
-I prefer (1) because the extra computation happens at the time the
-pattern is compiled rather than when it is executed.
-</p>
-<p>
--- End original message --
-</p>
-
-<p>
-For what it's worth, John has also expressed his preference for option
-(1) above.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
-</p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="527"></a>527. tr1::bind has lost its Throws clause</h3>
-<p><b>Section:</b> 20.6.11.1.3 [func.bind.bind], TR1 3.6.3 [tr.func.bind.bind] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2005-10-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#func.bind.bind">active issues</a> in [func.bind.bind].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#func.bind.bind">issues</a> in [func.bind.bind].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The original bind proposal gives the guarantee that tr1::bind(f, t1,
-..., tN) does not throw when the copy constructors of f, t1, ..., tN
-don't.
-</p>
-
-<p>
-This guarantee is not present in the final version of TR1.
-</p>
-
-<p>
-I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
-</p>
-
-<p><i>[
-Berlin: not quite editorial, needs proposed wording.
-]</i></p>
-
-<p><i>[
-Batavia: Doug to translate wording to variadic templates.
-]</i></p>
-
-
-<p><i>[
-Toronto: We agree but aren't quite happy with the wording. The "t"'s no
-longer refer to anything. Alan to provide improved wording.
-]</i></p>
-
-
-
-<p><i>[
-Pre-Bellevue: Alisdair provided wording.
-]</i></p>
-
-
-<p>
-TR1 proposed resolution:
-</p>
-
-<blockquote>
-<p>
-In TR1 3.6.3 [tr.func.bind.bind], add a new paragraph after p2:
-</p>
-<blockquote><p>
-<i>Throws:</i> Nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
-throws an exception.
-</p></blockquote>
-
-<p>
-Add a new paragraph after p4:
-</p>
-<blockquote><p>
-<i>Throws:</i> nothing unless one of the copy constructors of <tt>f, t1, t2, ..., tN</tt>
-throws an exception.
-</p></blockquote>
-
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p2:
-</p>
-
-<blockquote>
-<i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types
-in the <tt>BoundArgs...</tt> pack expansion throws an exception.
-</blockquote>
-
-<p>
-In 20.6.11.1.3 [func.bind.bind], add a new paragraph after p4:
-</p>
-
-<blockquote>
-<i>Throws:</i> Nothing unless the copy constructor of <tt>F</tt> or of one of the types
-in the <tt>BoundArgs...</tt> pack expansion throws an exception.
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="530"></a>530. Must elements of a string be contiguous?</h3>
-<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2005-11-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, which was incorporated into C++03, mandated
- that the elements of a vector must be stored in contiguous memory.
- Should the same also apply to <tt>basic_string</tt>?</p>
-
-<p>We almost require contiguity already. Clause 23.3.4 [multiset]
- defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing
- is a similar guarantee if we access the string's elements via the
- iterator interface.</p>
-
-<p>Given the existence of <tt>data()</tt>, and the definition of
- <tt>operator[]</tt> and <tt>at</tt> in terms of <tt>data</tt>,
- I don't believe it's possible to write a useful and standard-
- conforming <tt>basic_string</tt> that isn't contiguous. I'm not
- aware of any non-contiguous implementation. We should just require
- it.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>Add the following text to the end of 21.3 [basic.string],
-paragraph 2. </p>
-
-<blockquote>
- <p>The characters in a string are stored contiguously, meaning that if
- <tt>s</tt> is a <tt>basic_string&lt;charT, Allocator&gt;</tt>, then
- it obeys the identity
- <tt>&amp;*(s.begin() + n) == &amp;*s.begin() + n</tt>
- for all <tt>0 &lt;= n &lt; s.size()</tt>.
- </p>
-</blockquote>
-
-
-<p><b>Rationale:</b></p>
-<p>
-Not standardizing this existing practice does not give implementors more
-freedom. We thought it might a decade ago. But the vendors have spoken
-both with their implementations, and with their voice at the LWG
-meetings. The implementations are going to be contiguous no matter what
-the standard says. So the standard might as well give string clients
-more design choices.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="531"></a>531. array forms of unformatted input functions</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-11-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The array forms of unformatted input functions don't seem to have well-defined
-semantics for zero-element arrays in a couple of cases. The affected ones
-(<tt>istream::get()</tt> and <tt>istream::getline()</tt>) are supposed to
-terminate when <tt>(n - 1)</tt> characters are stored, which obviously can
-never be true when <tt>(n == 0)</tt> holds to start with. See
-c++std-lib-16071.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-I suggest changing 27.6.1.3, p7 (<tt>istream::get()</tt>), bullet 1 to read:
-</p>
- <ul>
- <li>
- <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
- are stored;
- </li>
- </ul>
-<p>
-Change 27.6.1.3, p9:
-</p>
-
-<blockquote><p>
-If the function stores no characters, it calls <tt>setstate(failbit)</tt> (which
-may throw <tt>ios_base::failure</tt> (27.4.4.3)). In any case, <ins>if <tt>(n
-&gt; 0)</tt> is true</ins> it then stores a null character into the next
-successive location of the array.
-</p></blockquote>
-
- <p>
-
-and similarly p17 (<tt>istream::getline()</tt>), bullet 3 to:
-
- </p>
- <ul>
- <li>
- <tt>(n &lt; 1)</tt> is true or <tt>(n - 1)</tt> characters
- are stored (in which case the function calls
- <tt>setstate(failbit)</tt>).
- </li>
- </ul>
-
- <p>
-
-In addition, to clarify that <tt>istream::getline()</tt> must not store the
-terminating NUL character unless the the array has non-zero size, Robert
-Klarer suggests in c++std-lib-16082 to change 27.6.1.3, p20 to read:
-
- </p>
- <blockquote><p>
-
-In any case, provided <tt>(n &gt; 0)</tt> is true, it then stores a null character
-(using charT()) into the next successive location of the array.
-
- </p></blockquote>
-
-<p><i>[
-post-Redmond: Pete noticed that the current resolution for <tt>get</tt> requires
-writing to out of bounds memory when <tt>n == 0</tt>. Martin provided fix.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="533"></a>533. typo in 2.2.3.10/1</h3>
-<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.10 [tr.util.smartptr.getdeleter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2005-11-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#DR">DR</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
-says:
-</p>
-<blockquote><p>
-If <tt>*this</tt> <i>owns</i> a deleter <tt>d</tt>...
-</p></blockquote>
-<p>
-but <tt>get_deleter</tt> is a free function!
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Therefore, I think should be:
-</p>
-<blockquote><p>
-If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>...
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="534"></a>534. Missing basic_string members</h3>
-<p><b>Section:</b> 21.3 [basic.string] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2005-11-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#basic.string">active issues</a> in [basic.string].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#basic.string">issues</a> in [basic.string].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-OK, we all know std::basic_string is bloated and already has way too
-many members. However, I propose it is missing 3 useful members that
-are often expected by users believing it is a close approximation of the
-container concept. All 3 are listed in table 71 as 'optional'
-</p>
-
-<p>
-i/ pop_back.
-</p>
-
-<p>
-This is the one I feel most strongly about, as I only just discovered it
-was missing as we are switching to a more conforming standard library
-&lt;g&gt;
-</p>
-
-<p>
-I find it particularly inconsistent to support push_back, but not
-pop_back.
-</p>
-
-<p>
-ii/ back.
-</p>
-
-<p>
-There are certainly cases where I want to examine the last character of
-a string before deciding to append, or to trim trailing path separators
-from directory names etc. *rbegin() somehow feels inelegant.
-</p>
-
-<p>
-iii/ front
-</p>
-
-<p>
-This one I don't feel strongly about, but if I can get the first two,
-this one feels that it should be added as a 'me too' for consistency.
-</p>
-
-<p>
-I believe this would be similarly useful to the data() member recently
-added to vector, or at() member added to the maps.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following members to definition of class template basic_string, 21.3p7
-</p>
-<blockquote><pre>void pop_back ()
-
-const charT &amp; front() const
-charT &amp; front()
-
-const charT &amp; back() const
-charT &amp; back()
-</pre></blockquote>
-<p>
-Add the following paragraphs to basic_string description
-</p>
-
-<p>
-21.3.4p5
-</p>
-<blockquote>
-<pre>const charT &amp; front() const
-charT &amp; front()
-</pre>
-<p>
-<i>Precondition:</i> <tt>!empty()</tt>
-</p>
-<p>
-<i>Effects:</i> Equivalent to <tt>operator[](0)</tt>.
-</p>
-</blockquote>
-
-<p>
-21.3.4p6
-</p>
-<blockquote>
-<pre>const charT &amp; back() const
-charT &amp; back()
-</pre>
-<p>
-<i>Precondition:</i> <tt>!empty()</tt>
-</p>
-<p>
-<i>Effects:</i> Equivalent to <tt>operator[]( size() - 1)</tt>.
-</p>
-</blockquote>
-
-<p>
-21.3.5.5p10
-</p>
-<blockquote>
-<pre>void pop_back ()
-</pre>
-<p>
-<i>Precondition:</i> <tt>!empty()</tt>
-</p>
-<p>
-<i>Effects:</i> Equivalent to <tt>erase( size() - 1, 1 )</tt>.
-</p>
-</blockquote>
-
-<p>
-Update Table 71: (optional sequence operations)
-Add basic_string to the list of containers for the following operations.
-</p>
-<blockquote><pre>a.front()
-a.back()
-a.push_back()
-a.pop_back()
-a[n]
-</pre></blockquote>
-
-<p><i>[
-Berlin: Has support. Alisdair provided wording.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="535"></a>535. std::string::swap specification poorly worded</h3>
-<p><b>Section:</b> 21.3.6.8 [string::swap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2005-12-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string::swap">issues</a> in [string::swap].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-std::string::swap currently says for effects and postcondition:
-</p>
-
-<blockquote>
-<p>
-<i>Effects:</i> Swaps the contents of the two strings.
-</p>
-
-<p>
-<i>Postcondition:</i> <tt>*this</tt> contains the characters that were in <tt><i>s</i></tt>,
-<tt><i>s</i></tt> contains the characters that were in <tt>*this</tt>.
-</p>
-</blockquote>
-
-<p>
-Specifying both Effects and Postcondition seems redundant, and the postcondition
-needs to be made stronger. Users would be unhappy if the characters were not in
-the same order after the swap.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<blockquote>
-<p>
-<del><i>Effects:</i> Swaps the contents of the two strings.</del>
-</p>
-
-<p>
-<i>Postcondition:</i> <tt>*this</tt> contains the <ins>same sequence of</ins>
-characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>,
-<tt><i>s</i></tt> contains the <ins>same sequence of</ins> characters that
-<del>were</del> <ins>was</ins> in <tt>*this</tt>.
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="537"></a>537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2006-02-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In the most recent working draft, I'm still seeing:
-</p>
-
-<blockquote><pre>seekg(off_type&amp; off, ios_base::seekdir dir)
-</pre></blockquote>
-
-<p>
-and
-</p>
-
-<blockquote><pre>seekp(pos_type&amp; pos)
-
-seekp(off_type&amp; off, ios_base::seekdir dir)
-</pre></blockquote>
-
-<p>
-that is, by reference off and pos arguments.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-After 27.6.1.3p42 change:
-</p>
-
-<blockquote><pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
-</pre></blockquote>
-
-<p>
-After 27.6.2.4p1 change:
-</p>
-
-<blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(pos_type<del>&amp;</del> <i>pos</i>);
-</pre></blockquote>
-
-<p>
-After 27.6.2.4p3 change:
-</p>
-
-<blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="538"></a>538. 241 again: Does unique_copy() require CopyConstructible and Assignable?</h3>
-<p><b>Section:</b> 25.2.9 [alg.unique] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.unique">issues</a> in [alg.unique].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I believe I botched the resolution of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">
-241 "Does unique_copy() require CopyConstructible and Assignable?"</a> which now
-has WP status.
-</p>
-
-<p>
-This talks about <tt>unique_copy</tt> requirements and currently reads:
-</p>
-
-<blockquote><p>
--5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
-<tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
-shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt> shall
-be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
-requirements of forward iterator then the value type of <tt>InputIterator</tt>
-must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required.
-</p></blockquote>
-
-<p>
-The problem (which Paolo discovered) is that when the iterators are at their
-most restrictive (<tt>InputIterator</tt>, <tt>OutputIterator</tt>), then we want
-<tt>InputIterator::value_type</tt> to be both <tt>CopyConstructible</tt> and
-<tt>CopyAssignable</tt> (for the most efficient implementation). However this
-proposed resolution only makes it clear that it is <tt>CopyConstructible</tt>,
-and that one can assign from <tt>*<i>first</i></tt> to <tt>*<i>result</i></tt>.
-This latter requirement does not necessarily imply that you can:
-</p>
-
-<blockquote><pre>*<i>first</i> = *<i>first</i>;
-</pre></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<blockquote><p>
--5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
-<tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
-shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt>
-shall
-be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
-requirements of forward iterator then the <del>value type</del>
-<ins><tt>value_type</tt></ins> of <tt>InputIterator</tt>
-must be CopyConstructible (20.1.3) <ins>and Assignable</ins>.
-Otherwise CopyConstructible is not required.
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="540"></a>540. shared_ptr&lt;void&gt;::operator*()</h3>
-<p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
-that talks about the operator*() member function of shared_ptr:
-</p>
-
-<blockquote><p>
- Notes: When T is void, attempting to instantiate this member function
- renders the program ill-formed. [Note: Instantiating shared_ptr&lt;void&gt;
- does not necessarily result in instantiating this member function.
- --end note]
-</p></blockquote>
-
-<p>
-with the requirement in temp.inst, p1:
-</p>
-
-<blockquote><p>
- The implicit instantiation of a class template specialization causes
- the implicit instantiation of the declarations, but not of the
- definitions...
-</p></blockquote>
-
-<p>
-I assume that what the note is really trying to say is that
-"instantiating shared_ptr&lt;void&gt; *must not* result in instantiating
-this member function." That is, that this function must not be
-declared a member of shared_ptr&lt;void&gt;. Is my interpretation
-correct?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 2.2.3.5p6
-</p>
-
-<blockquote><p>
--6- <del><i>Notes:</i></del> When <tt>T</tt> is <tt>void</tt>, <del>attempting to instantiate
-this member function renders the program ill-formed. [<i>Note:</i>
-Instantiating <tt>shared_ptr&lt;void&gt;</tt> does not necessarily result in
-instantiating this member function. <i>--end note</i>]</del> <ins>it is
-unspecified whether this member function is declared or not, and if so, what its
-return type is, except that the declaration (although not necessarily the
-definition) of the function shall be well-formed.</ins>
-</p></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="541"></a>541. shared_ptr template assignment and void</h3>
-<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared], TR1 2.2.3 [tr.util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-16</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Is the void specialization of the template assignment operator taking
-a shared_ptr&lt;void&gt; as an argument supposed be well-formed?
-</p>
-<p>
-I.e., is this snippet well-formed:
-</p>
-<blockquote><pre>shared_ptr&lt;void&gt; p;
-p.operator=&lt;void&gt;(p);
-</pre></blockquote>
-
-<p>
-Gcc complains about auto_ptr&lt;void&gt;::operator*() returning a reference
-to void. I suspect it's because shared_ptr has two template assignment
-operators, one of which takes auto_ptr, and the auto_ptr template gets
-implicitly instantiated in the process of overload resolution.
-</p>
-
-<p>
-The only way I see around it is to do the same trick with auto_ptr&lt;void&gt;
-operator*() as with the same operator in shared_ptr&lt;void&gt;.
-</p>
-
-<p>
-PS Strangely enough, the EDG front end doesn't mind the code, even
-though in a small test case (below) I can reproduce the error with
-it as well.
-</p>
-
-<blockquote><pre>template &lt;class T&gt;
-struct A { T&amp; operator*() { return *(T*)0; } };
-
-template &lt;class T&gt;
-struct B {
- void operator= (const B&amp;) { }
- template &lt;class U&gt;
- void operator= (const B&lt;U&gt;&amp;) { }
- template &lt;class U&gt;
- void operator= (const A&lt;U&gt;&amp;) { }
-};
-
-int main ()
-{
- B&lt;void&gt; b;
- b.operator=&lt;void&gt;(b);
-}
-</pre></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In [lib.memory] change:
-</p>
-<blockquote><pre>template&lt;class X&gt; class auto_ptr;
-<ins>template&lt;&gt; class auto_ptr&lt;void&gt;;</ins>
-</pre></blockquote>
-
-<p>
-In [lib.auto.ptr]/2 add the following before the last closing brace:
-</p>
-
-<blockquote><pre>template&lt;&gt; class auto_ptr&lt;void&gt;
-{
-public:
- typedef void element_type;
-};
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="542"></a>542. shared_ptr observers</h3>
-<p><b>Section:</b> 20.7.12.2.5 [util.smartptr.shared.obs], TR1 2.2.3.5 [tr.util.smartptr.shared.obs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2005-10-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.obs">issues</a> in [util.smartptr.shared.obs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Peter Dimov wrote:
-To: C++ libraries mailing list
-Message c++std-lib-15614
-[...]
-The intent is for both use_count() and unique() to work in a threaded environment.
-They are intrinsically prone to race conditions, but they never return garbage.
-</p>
-
-<p>
-This is a crucial piece of information that I really wish were
-captured in the text. Having this in a non-normative note would
-have made everything crystal clear to me and probably stopped
-me from ever starting this discussion :) Instead, the sentence
-in p12 "use only for debugging and testing purposes, not for
-production code" very strongly suggests that implementations
-can and even are encouraged to return garbage (when threads
-are involved) for performance reasons.
-</p>
-<p>
-How about adding an informative note along these lines:
-</p>
-<blockquote><p>
- Note: Implementations are encouraged to provide well-defined
- behavior for use_count() and unique() even in the presence of
- multiple threads.
-</p></blockquote>
-<p>
-I don't necessarily insist on the exact wording, just that we
-capture the intent.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.7.12.2.5 [util.smartptr.shared.obs] p12:
-</p>
-<blockquote><p>
-[<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
-debugging and testing purposes, not for production code.</del> --<i>end note</i>]
-</p></blockquote>
-
-<p>
-Change 20.7.12.3.5 [util.smartptr.weak.obs] p3:
-</p>
-<blockquote><p>
-[<i>Note:</i> <tt>use_count()</tt> is not necessarily efficient. <del>Use only for
-debugging and testing purposes, not for production code.</del> --<i>end note</i>]
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="543"></a>543. valarray slice default constructor</h3>
-<p><b>Section:</b> 26.5.4 [class.slice] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2005-11-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-If one explicitly constructs a slice or glice with the default
-constructor, does the standard require this slice to have any usable
-state? It says "creates a slice which specifies no elements", which
-could be interpreted two ways:
-</p>
-<ol>
-<li>There are no elements to which the slice refers (i.e. undefined).</li>
-<li>The slice specifies an array with no elements in it (i.e. defined).</li>
-</ol>
-<p>
-Here is a bit of code to illustrate:
-</p>
-<blockquote><pre>#include &lt;iostream&gt;
-#include &lt;valarray&gt;
-
-int main()
-{
- std::valarray&lt;int&gt; v(10);
- std::valarray&lt;int&gt; v2 = v[std::slice()];
- std::cout &lt;&lt; "v[slice()].size() = " &lt;&lt; v2.size() &lt;&lt; '\n';
-}
-</pre></blockquote>
-
-<p>
-Is the behavior undefined? Or should the output be:
-</p>
-
-<blockquote><pre>v[slice()].size() = 0
-</pre></blockquote>
-
-<p>
-There is a similar question and wording for gslice at 26.3.6.1p1.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p><i>[Martin suggests removing the second sentence in 26.5.4.1 [cons.slice] as well.]</i></p>
-
-
-<p>
-Change 26.5.4.1 [cons.slice]:
-</p>
-
-<blockquote><p>
-1 - <del>The default constructor for <tt>slice</tt> creates a <tt>slice</tt>
-which specifies no elements.</del> <ins>The default constructor is equivalent to
-<tt>slice(0, 0, 0)</tt>.</ins> A default constructor is provided only to permit
-the declaration of arrays of slices. The constructor with arguments for a slice
-takes a start, length, and stride parameter.
-</p></blockquote>
-
-<p>
-Change 26.5.6.1 [gslice.cons]:
-</p>
-
-<blockquote><p>
-1 - <del>The default constructor creates a <tt>gslice</tt> which specifies no
-elements.</del> <ins>The default constructor is equivalent to <tt>gslice(0,
-valarray&lt;size_t&gt;(), valarray&lt;size_t&gt;())</tt>.</ins> The constructor
-with arguments builds a <tt>gslice</tt> based on a specification of start,
-lengths, and strides, as explained in the previous section.
-</p></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="545"></a>545. When is a deleter deleted?</h3>
-<p><b>Section:</b> 20.7.12.2.11 [util.smartptr.getdeleter], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2006-01-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.getdeleter">issues</a> in [util.smartptr.getdeleter].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if
-any, is destroyed. In principle there are two possibilities: it is destroyed
-unconditionally whenever ~shared_ptr is executed (which, from an implementation
-standpoint, means that the deleter is copied whenever the shared_ptr is copied),
-or it is destroyed immediately after the owned pointer is destroyed (which, from
-an implementation standpoint, means that the deleter object is shared between
-instances). We should say which it is.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add after the first sentence of 20.7.12.2.11 [util.smartptr.getdeleter]/1:
-</p>
-<blockquote>
-<p>
-The returned pointer remains valid as long as there exists a <tt>shared_ptr</tt> instance
-that owns <tt><i>d</i></tt>.
-</p>
-<p>
-[<i>Note:</i> it is unspecified whether the pointer remains valid longer than that.
-This can happen if the implementation doesn't destroy the deleter until all
-<tt>weak_ptr</tt> instances in the ownership group are destroyed. <i>-- end note</i>]
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="550"></a>550. What should the return type of pow(float,int) be?</h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-12</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Assuming we adopt the
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">C
-compatibility package from C99</a> what should be the return type of the
-following signature be:
-</p>
-<blockquote><pre>? pow(float, int);
-</pre></blockquote>
-<p>
-C++03 says that the return type should be <tt>float</tt>.
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
-TR1</a> and C90/99 say the return type should be <tt>double</tt>. This can put
-clients into a situation where C++03 provides answers that are not as high
-quality as C90/C99/TR1. For example:
-</p>
-<blockquote><pre>#include &lt;math.h&gt;
-
-int main()
-{
- float x = 2080703.375F;
- double y = pow(x, 2);
-}
-</pre></blockquote>
-<p>
-Assuming an IEEE 32 bit float and IEEE 64 bit double, C90/C99/TR1 all suggest:
-</p>
-
-<blockquote><pre>y = 4329326534736.390625
-</pre></blockquote>
-
-<p>
-which is exactly right. While C++98/C++03 demands:
-</p>
-
-<blockquote><pre>y = 4329326510080.
-</pre></blockquote>
-
-<p>
-which is only approximately right.
-</p>
-
-<p>
-I recommend that C++0X adopt the mixed mode arithmetic already adopted by
-Fortran, C and TR1 and make the return type of <tt>pow(float,int)</tt> be
-<tt>double</tt>.
-</p>
-
-<p><i>[
-Kona (2007): Other functions that are affected by this issue include
-<tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt>. We also believe that there is a typo in
-26.7/10: <tt>float nexttoward(float, long double);</tt> [sic] should be <tt>float
-nexttoward(float, float);</tt> Proposed Disposition: Review (the proposed
-resolution appears above, rather than below, the heading "Proposed
-resolution")
-]</i></p>
-
-
-<p><i>[
-<p>
-Howard, post Kona:
-</p>
-<blockquote>
-<p>
-Unfortunately I strongly disagree with a part of the resolution
-from Kona. I am moving from New to Open instead of to Review because I do not believe
-we have consensus on the intent of the resolution.
-</p>
-<p>
-This issue does not include <tt>ldexp</tt>, <tt>scalbln</tt>, and <tt>scalbn</tt> because
-the second integral parameter in each of these signatures (from C99) is <b>not</b> a
-<i>generic parameter</i> according to C99 7.22p2. The corresponding C++ overloads are
-intended (as far as I know) to correspond directly to C99's definition of <i>generic parameter</i>.
-</p>
-<p>
-For similar reasons, I do not believe that the second <tt>long double</tt> parameter of
-<tt>nexttoward</tt>, nor the return type of this function, is in error. I believe the
-correct signature is:
-</p>
-<blockquote>
-<pre>float nexttoward(float, long double);
-</pre>
-</blockquote>
-<p>
-which is what both the C++0X working paper and C99 state (as far as I currently understand).
-</p>
-<p>
-This is really <b>only</b> about <tt>pow(float, int)</tt>. And this is because C++98 took one
-route (with <tt>pow</tt> only) and C99 took another (with many math functions in <tt>&lt;tgmath.h&gt;</tt>.
-The proposed resolution basically says: C++98 got it wrong and C99 got it right; let's go with C99.
-</p>
-</blockquote>
-]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-This signature was not picked up from C99. Instead, if one types
-pow(2.0f,2), the promotion rules will invoke "double pow(double,
-double)", which generally gives special treatment for integral
-exponents, preserving full accuracy of the result. New proposed
-wording provided.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.7 [c.math] p10:
-</p>
-
-<blockquote>
-<p>
-The added signatures are:
-</p>
-<blockquote><pre>...
-<del>float pow(float, int);</del>
-...
-<del>double pow(double, int);</del>
-...
-<del>long double pow(long double, int);</del>
-</pre></blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="551"></a>551. &lt;ccomplex&gt;</h3>
-<p><b>Section:</b> 26.3.11 [cmplxh], TR1 8.3 [tr.c99.cmplxh] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-01-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Previously xxx.h was parsable by C++. But in the case of C99's &lt;complex.h&gt;
-it isn't. Otherwise we could model it just like &lt;string.h&gt;, &lt;cstring&gt;, &lt;string&gt;:
-</p>
-
-<ul>
-<li>&lt;string&gt; : C++ API in namespace std</li>
-<li>&lt;cstring&gt; : C API in namespace std</li>
-<li>&lt;string.h&gt; : C API in global namespace</li>
-</ul>
-
-<p>
-In the case of C's complex, the C API won't compile in C++. So we have:
-</p>
-
-<ul>
-<li>&lt;complex&gt; : C++ API in namespace std</li>
-<li>&lt;ccomplex&gt; : ?</li>
-<li>&lt;complex.h&gt; : ?</li>
-</ul>
-
-<p>
-The ? can't refer to the C API. TR1 currently says:
-</p>
-
-<ul>
-<li>&lt;complex&gt; : C++ API in namespace std</li>
-<li>&lt;ccomplex&gt; : C++ API in namespace std</li>
-<li>&lt;complex.h&gt; : C++ API in global namespace</li>
-</ul>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.3.11 [cmplxh]:
-</p>
-
-<blockquote>
-<p>
-The header behaves as if it includes the header
-<tt>&lt;ccomplex&gt;</tt><ins>.</ins><del>, and provides sufficient using
-declarations to declare in the global namespace all function and type names
-declared or defined in the neader <tt>&lt;complex&gt;</tt>.</del>
-<ins>[<i>Note:</i> <tt>&lt;complex.h&gt;</tt> does not promote any interface
-into the global namespace as there is no C interface to promote. <i>--end
-note</i>]</ins>
-</p>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="552"></a>552. random_shuffle and its generator</h3>
-<p><b>Section:</b> 25.2.12 [alg.random.shuffle] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-01-25</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-...is specified to shuffle its range by calling swap but not how
-(or even that) it's supposed to use the RandomNumberGenerator
-argument passed to it.
-</p>
-<p>
-Shouldn't we require that the generator object actually be used
-by the algorithm to obtain a series of random numbers and specify
-how many times its operator() should be invoked by the algorithm?
-</p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
-</p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="559"></a>559. numeric_limits&lt;const T&gt;</h3>
-<p><b>Section:</b> 18.2.1 [limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-19</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#limits">issues</a> in [limits].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-18.2.1 [limits], p2 requires implementations to provide specializations of the
-<code>numeric_limits</code> template for each scalar type. While this
-could be interepreted to include cv-qualified forms of such types such
-an interepretation is not reflected in the synopsis of the
-<code>&lt;limits&gt;</code> header.
-
- </p>
- <p>
-
-The absence of specializations of the template on cv-qualified forms
-of fundamental types makes <code>numeric_limits</code> difficult to
-use in generic code where the constness (or volatility) of a type is
-not always immediately apparent. In such contexts, the primary
-template ends up being instantiated instead of the provided
-specialization, typically yielding unexpected behavior.
-
- </p>
- <p>
-
-Require that specializations of <code>numeric_limits</code> on
-cv-qualified fundamental types have the same semantics as those on the
-unqualifed forms of the same types.
-
- </p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-Add to the synopsis of the <code>&lt;limits&gt;</code> header,
-immediately below the declaration of the primary template, the
-following:
-</p>
-
-<pre>
-template &lt;class T&gt; class numeric_limits&lt;const T&gt;;
-template &lt;class T&gt; class numeric_limits&lt;volatile T&gt;;
-template &lt;class T&gt; class numeric_limits&lt;const volatile T&gt;;
-
-</pre>
-
- <p>
-
-Add a new paragraph to the end of 18.2.1.1 [numeric.limits], with the following
-text:
-
- </p>
- <p>
-
--new-para- The value of each member of a <code>numeric_limits</code>
-specialization on a cv-qualified T is equal to the value of the same
-member of <code>numeric_limits&lt;T&gt;</code>.
-
- </p>
-
-<p><i>[
-Portland: Martin will clarify that user-defined types get cv-specializations
-automatically.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="561"></a>561. inserter overly generic</h3>
-<p><b>Section:</b> 24.4.2.6.5 [inserter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2006-02-21</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The declaration of <tt>std::inserter</tt> is:
-</p>
-
-<blockquote><pre>template &lt;class Container, class Iterator&gt;
-insert_iterator&lt;Container&gt;
-inserter(Container&amp; x, Iterator i);
-</pre></blockquote>
-
-<p>
-The template parameter <tt>Iterator</tt> in this function is completely unrelated
-to the template parameter <tt>Container</tt> when it doesn't need to be. This
-causes the code to be overly generic. That is, any type at all can be deduced
-as <tt>Iterator</tt>, whether or not it makes sense. Now the same is true of
-<tt>Container</tt>. However, for every free (unconstrained) template parameter
-one has in a signature, the opportunity for a mistaken binding grows geometrically.
-</p>
-
-<p>
-It would be much better if <tt>inserter</tt> had the following signature instead:
-</p>
-
-<blockquote><pre>template &lt;class Container&gt;
-insert_iterator&lt;Container&gt;
-inserter(Container&amp; x, typename Container::iterator i);
-</pre></blockquote>
-
-<p>
-Now there is only one free template parameter. And the second argument to
-<tt>inserter</tt> must be implicitly convertible to the container's iterator,
-else the call will not be a viable overload (allowing other functions in the
-overload set to take precedence). Furthermore, the first parameter must have a
-nested type named <tt>iterator</tt>, or again the binding to <tt>std::inserter</tt>
-is not viable. Contrast this with the current situation
-where any type can bind to <tt>Container</tt> or <tt>Iterator</tt> and those
-types need not be anything closely related to containers or iterators.
-</p>
-
-<p>
-This can adversely impact well written code. Consider:
-</p>
-
-<blockquote><pre>#include &lt;iterator&gt;
-#include &lt;string&gt;
-
-namespace my
-{
-
-template &lt;class String&gt;
-struct my_type {};
-
-struct my_container
-{
-template &lt;class String&gt;
-void push_back(const my_type&lt;String&gt;&amp;);
-};
-
-template &lt;class String&gt;
-void inserter(const my_type&lt;String&gt;&amp; m, my_container&amp; c) {c.push_back(m);}
-
-} // my
-
-int main()
-{
- my::my_container c;
- my::my_type&lt;std::string&gt; m;
- inserter(m, c);
-}
-</pre></blockquote>
-
-<p>
-Today this code fails because the call to <tt>inserter</tt> binds to
-<tt>std::inserter</tt> instead of to <tt>my::inserter</tt>. However with the
-proposed change <tt>std::inserter</tt> will no longer be a viable function which
-leaves only <tt>my::inserter</tt> in the overload resolution set. Everything
-works as the client intends.
-</p>
-
-<p>
-To make matters a little more insidious, the above example works today if you
-simply change the first argument to an rvalue:
-</p>
-
-<blockquote><pre> inserter(my::my_type(), c);
-</pre></blockquote>
-
-<p>
-It will also work if instantiated with some string type other than
-<tt>std::string</tt> (or any other <tt>std</tt> type). It will also work if
-<tt>&lt;iterator&gt;</tt> happens to not get included.
-</p>
-
-<p>
-And it will fail again for such inocuous reaons as <tt>my_type</tt> or
-<tt>my_container</tt> privately deriving from any <tt>std</tt> type.
-</p>
-
-<p>
-It seems unfortunate that such simple changes in the client's code can result
-in such radically differing behavior.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 24.2:
-</p>
-
-<blockquote><p>
-<b>24.2 Header</b> <tt>&lt;iterator&gt;</tt> <b>synopsis</b>
-</p>
-<blockquote><pre>...
-template &lt;class Container<del>, class Iterator</del>&gt;
- insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
-...
-</pre></blockquote>
-</blockquote>
-
-<p>
-Change 24.4.2.5:
-</p>
-
-<blockquote><p>
-<b>24.4.2.5 Class template</b> <tt>insert_iterator</tt></p>
-<blockquote><pre>...
-template &lt;class Container<del>, class Iterator</del>&gt;
- insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Iterator</del> <ins>typename Container::iterator</ins> i);
-...
-</pre></blockquote>
-</blockquote>
-
-<p>
-Change 24.4.2.6.5:
-</p>
-
-<blockquote>
-<p>
-<b>24.4.2.6.5</b> <tt>inserter</tt>
-</p>
-<pre>template &lt;class Container<del>, class Inserter</del>&gt;
- insert_iterator&lt;Container&gt; inserter(Container&amp; x, <del>Inserter</del> <ins>typename Container::iterator</ins> i);
-</pre>
-<blockquote><p>
--1- <i>Returns:</i> <tt>insert_iterator&lt;Container&gt;(x,<del>typename Container::iterator(</del>i<del>)</del>)</tt>.
-</p></blockquote>
-</blockquote>
-
-
-
-<p><i>[
-Kona (2007): This issue will probably be addressed as a part of the
-concepts overhaul of the library anyway, but the proposed resolution is
-correct in the absence of concepts. Proposed Disposition: Ready
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="562"></a>562. stringbuf ctor inefficient</h3>
-<p><b>Section:</b> 27.7 [string.streams] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.streams">issues</a> in [string.streams].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-For better efficiency, the requirement on the stringbuf ctor that
-takes a string argument should be loosened up to let it set
-<code>epptr()</code> beyond just one past the last initialized
-character just like <code>overflow()</code> has been changed to be
-allowed to do (see issue 432). That way the first call to
-<code>sputc()</code> on an object won't necessarily cause a call to
-<code>overflow</code>. The corresponding change should be made to the
-string overload of the <code>str()</code> member function.
-
- </p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-Change 27.7.1.1, p3 of the Working Draft, N1804, as follows:
-
- </p>
-
-<blockquote><pre>explicit basic_stringbuf(const basic_string&lt;charT,traits,Allocator&gt;&amp; <i>s<del>tr</del></i>,
- ios_base::openmode <i>which</i> = ios_base::in | ios_base::out);
-</pre>
-
-<p>
--3- <i>Effects:</i> Constructs an object of class <tt>basic_stringbuf</tt>,
-initializing the base class with <tt>basic_streambuf()</tt>
-(27.5.2.1), and initializing <tt><i>mode</i></tt> with <tt><i>which</i></tt>.
-Then <ins>calls <tt>str(<i>s</i>)</tt>.</ins> <del>copies the content of
-<i>str</i> into the <tt>basic_stringbuf</tt> underlying character
-sequence. If <tt><i>which</i> &amp; ios_base::out</tt> is true, initializes the
-output sequence such that <tt>pbase()</tt> points to the first underlying
-character, <tt>epptr()</tt> points one past the last underlying character, and
-<tt>pptr()</tt> is equal to <tt>epptr()</tt> if <tt><i>which</i> &amp; ios_base::ate</tt>
-is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
-<tt>which &amp; ios_base::in</tt> is true, initializes the input sequence such
-that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying
-character and <tt>egptr()</tt> points one past the last underlying character.</del>
-</p>
-</blockquote>
-
- <p>
-
-Change the Effects clause of the <code>str()</code> in 27.7.1.2, p2 to
-read:
-
- </p>
-<blockquote>
-<p>
--2- <i>Effects:</i> Copies the content<ins>s</ins> of <tt><i>s</i></tt> into the
-<tt>basic_stringbuf</tt> underlying character sequence <ins>and
-initializes the input and output sequences according to <tt><i>mode</i></tt></ins>.
-<del>If
-<tt><i>mode</i> &amp; ios_base::out</tt> is true, initializes the output
-sequence such that <tt>pbase()</tt> points to the first underlying character,
-<tt>epptr()</tt> points one past the last underlying character, and <tt>pptr()</tt>
-is equal to <tt>epptr()</tt> if <tt><i>mode</i> &amp; ios_base::in</tt>
-is true, otherwise <tt>pptr()</tt> is equal to <tt>pbase()</tt>. If
-<tt>mode &amp; ios_base::in</tt> is true, initializes the input sequence
-such that <tt>eback()</tt> and <tt>gptr()</tt> point to the first underlying
-character and <tt>egptr()</tt> points one past the last underlying character.</del>
-</p>
-
- <p>
-
-<ins>-3- <i>Postconditions:</i> If <code>mode &amp; ios_base::out</code> is true,
-<code>pbase()</code> points to the first underlying character and
-<code>(epptr() &gt;= pbase() + s.size())</code> holds; in addition, if
-<code>mode &amp; ios_base::in</code> is true, <code>(pptr() == pbase()
-+ s.data())</code> holds, otherwise <code>(pptr() == pbase())</code>
-is true. If <code>mode &amp; ios_base::in</code> is true,
-<code>eback()</code> points to the first underlying character, and
-<code>(gptr() == eback())</code> and <code>(egptr() == eback() +
-s.size())</code> hold.</ins>
-
- </p>
-</blockquote>
-
-
-<p><i>[
-Kona (2007) Moved to Ready.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="563"></a>563. stringbuf seeking from end</h3>
-<p><b>Section:</b> 27.7.1.4 [stringbuf.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#stringbuf.virtuals">issues</a> in [stringbuf.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-According to Table 92 (unchanged by issue 432), when <code>(way ==
-end)</code> the <code>newoff</code> value in out mode is computed as
-the difference between <code>epptr()</code> and <code>pbase()</code>.
-</p>
- <p>
-
-This value isn't meaningful unless the value of <code>epptr()</code>
-can be precisely controlled by a program. That used to be possible
-until we accepted the resolution of issue 432, but since then the
-requirements on <code>overflow()</code> have been relaxed to allow it
-to make more than 1 write position available (i.e., by setting
-<code>epptr()</code> to some unspecified value past
-<code>pptr()</code>). So after the first call to
-<code>overflow()</code> positioning the output sequence relative to
-end will have unspecified results.
-
- </p>
- <p>
-
-In addition, in <code>in|out</code> mode, since <code>(egptr() ==
-epptr())</code> need not hold, there are two different possible values
-for <code>newoff</code>: <code>epptr() - pbase()</code> and
-<code>egptr() - eback()</code>.
-
- </p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-Change the <code>newoff</code> column in the last row of Table 94 to
-read:
-
- </p>
-<blockquote><p>
-
-the <del>end</del> <ins>high mark</ins> pointer minus the beginning
-pointer (<code><del>xend</del> <ins>high_mark</ins> - xbeg</code>).
-
-</p></blockquote>
-
-
-<p><i>[
-Kona (2007) Moved to Ready.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="566"></a>566. array forms of unformatted input function undefined for zero-element arrays</h3>
-<p><b>Section:</b> 27.6.1.3 [istream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The array forms of unformatted input functions don't have well-defined
-semantics for zero-element arrays in a couple of cases. The affected
-ones (<tt>istream::get()</tt> and <tt>getline()</tt>) are supposed to
-terminate when <tt>(n - 1)</tt> characters are stored, which obviously
-can never be true when <tt>(n == 0)</tt> to start with.
-
- </p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-I propose the following changes (references are relative to the
-Working Draft (document N1804).
-
- </p>
- <p>
-
-Change 27.6.1.3, p8 (<tt>istream::get()</tt>), bullet 1 as follows:
-
- </p>
- <blockquote>
- <p>
-
-<ins>if <tt>(n &lt; 1)</tt> is true or </ins> <tt>(n - 1)</tt>
-characters are stored;
-
- </p>
- </blockquote>
- <p>
-
-Similarly, change 27.6.1.3, p18 (<tt>istream::getline()</tt>), bullet
-3 as follows:
-
- </p>
- <blockquote>
- <p>
-
-<ins><tt>(n &lt; 1)</tt> is true or </ins><tt>(n - 1)</tt> characters
-are stored (in which case the function calls
-<tt>setstate(failbit)</tt>).
-
- </p>
- </blockquote>
- <p>
-
-Finally, change p21 as follows:
-
- </p>
- <blockquote>
- <p>
-
-In any case, <ins>provided <tt>(n &gt; 0)</tt> is true, </ins>it then
-stores a null character (using charT()) into the next successive
-location of the array.
-
- </p>
- </blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="567"></a>567. streambuf inserter and extractor should be unformatted</h3>
-<p><b>Section:</b> 27.6 [iostream.format] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-02-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.format">issues</a> in [iostream.format].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-Issue 60 explicitly made the extractor and inserter operators that
-take a <tt>basic_streambuf*</tt> argument formatted input and output
-functions, respectively. I believe that's wrong, certainly in the
-case of the extractor, since formatted functions begin by extracting
-and discarding whitespace. The extractor should not discard any
-characters.
-
- </p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-I propose to change each operator to behave as unformatted input and
-output function, respectively. The changes below are relative to the
-working draft document number N1804.
-
- </p>
- <p>
-
-Specifically, change 27.6.1.2.3, p14 as follows:
-
- </p>
-
- <blockquote>
- <p>
-
-<i>Effects</i>: Behaves as a<ins>n un</ins>formatted input function
-(as described in <del>27.6.1.2.1</del><ins>27.6.1.3, paragraph
-1</ins>).
-
- </p>
- </blockquote>
- <p>
-
-And change 27.6.2.5.3, p7 as follows:
-
- </p>
-
- <blockquote>
- <p>
-
-<i>Effects</i>: Behaves as a<ins>n un</ins>formatted output function
-(as described in <del>27.6.2.5.1</del><ins>27.6.2.6, paragraph
-1</ins>).
-
- </p>
- </blockquote>
-
-
-<p><i>[
-Kona (2007): Proposed Disposition: Ready
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="574"></a>574. DR 369 Contradicts Text</h3>
-<p><b>Section:</b> 27.3 [iostream.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Pete Becker <b>Date:</b> 2006-04-18</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#iostream.objects">issues</a> in [iostream.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-lib.iostream.objects requires that the standard stream objects are never
-destroyed, and it requires that they be destroyed.
-</p>
-<p>
-DR 369 adds words to say that we really mean for ios_base::Init objects to force
-construction of standard stream objects. It ends, though, with the phrase "these
-stream objects shall be destroyed after the destruction of dynamically ...".
-However, the rule for destruction is stated in the standard: "The objects are
-not destroyed during program execution."
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 27.3 [iostream.objects]/1:
-</p>
-
-<blockquote>
-<p>
--2- The objects are constructed and the associations are established at
-some time prior to or during the first time an object of class
-<tt>ios_base::Init</tt> is constructed, and in any case before the body of main
-begins execution.<sup>290)</sup> The objects are not destroyed during program
-execution.<sup>291)</sup> If a translation unit includes <tt>&lt;iostream&amp;t;</tt> or explicitly
-constructs an <tt>ios_base::Init</tt> object, these stream objects shall be
-constructed before dynamic initialization of non-local objects defined
-later in that translation unit<del>, and these stream objects shall be
-destroyed after the destruction of dynamically initialized non-local
-objects defined later in that translation unit</del>.
-</p>
-</blockquote>
-
-
-<p><i>[
-Kona (2007): From 27.3 [iostream.objects]/2, strike the words "...and these stream objects
-shall be destroyed after the destruction of dynamically initialized
-non-local objects defined later in that translation unit." Proposed
-Disposition: Review
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="575"></a>575. the specification of ~shared_ptr is MT-unfriendly, makes implementation assumptions</h3>
-<p><b>Section:</b> 20.7.12.2.2 [util.smartptr.shared.dest], TR1 2.2.3.2 [tr.util.smartptr.shared.dest] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-04-23</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-[tr.util.smartptr.shared.dest] says in its second bullet:
-</p>
-
-<p>
-"If *this shares ownership with another shared_ptr instance (use_count() &gt; 1),
-decrements that instance's use count."
-</p>
-
-<p>
-The problem with this formulation is that it presupposes the existence of an
-"use count" variable that can be decremented and that is part of the state of a
-shared_ptr instance (because of the "that instance's use count".)
-</p>
-
-<p>
-This is contrary to the spirit of the rest of the specification that carefully
-avoids to require an use count variable. Instead, use_count() is specified to
-return a value, a number of instances.
-</p>
-
-<p>
-In multithreaded code, the usual implicit assumption is that a shared variable
-should not be accessed by more than one thread without explicit synchronization,
-and by introducing the concept of an "use count" variable, the current wording
-implies that two shared_ptr instances that share ownership cannot be destroyed
-simultaneously.
-</p>
-
-<p>
-In addition, if we allow the interpretation that an use count variable is part
-of shared_ptr's state, this would lead to other undesirable consequences WRT
-multiple threads. For example,
-</p>
-
-<blockquote><pre>p1 = p2;
-</pre></blockquote>
-
-<p>
-would now visibly modify the state of p2, a "write" operation, requiring a lock.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the first two bullets of [lib.util.smartptr.shared.dest]/1 to:
-</p>
-
-<blockquote>
-<ul>
-<li>If <tt>*this</tt> is <i>empty</i> <ins>or shares ownership with another
-<tt>shared_ptr</tt> instance (<tt>use_count() &gt; 1</tt>)</ins>, there are no side effects.</li>
-<li><del>If <tt>*this</tt> <i>shares ownership</i> with another <tt>shared_ptr</tt> instance
-(<tt>use_count() &gt; 1</tt>), decrements that instance's use count.</del></li>
-</ul>
-</blockquote>
-
-<p>
-Add the following paragraph after [lib.util.smartptr.shared.dest]/1:
-</p>
-
-<blockquote><p>
-[<i>Note:</i> since the destruction of <tt>*this</tt> decreases the number of instances in
-<tt>*this</tt>'s ownership group by one, all <tt>shared_ptr</tt> instances that share ownership
-with <tt>*this</tt> will report an <tt>use_count()</tt> that is one lower than its previous value
-after <tt>*this</tt> is destroyed. <i>--end note</i>]
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="576"></a>576. find_first_of is overconstrained</h3>
-<p><b>Section:</b> 25.1.7 [alg.find.first.of] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Doug Gregor <b>Date:</b> 2006-04-25</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.find.first.of">issues</a> in [alg.find.first.of].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 25.1.4 Find First [lib.alg.find.first], the two iterator type parameters to
-find_first_of are specified to require Forward Iterators, as follows:
-</p>
-
-<blockquote><pre>template&lt;class ForwardIterator1, class ForwardIterator2&gt;
- ForwardIterator1
- find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
- ForwardIterator2 first2, ForwardIterator2 last2);
-template&lt;class ForwardIterator1, class ForwardIterator2,
- class BinaryPredicate&gt;
-ForwardIterator1
- find_first_of(ForwardIterator1 first1, ForwardIterator1 last1,
- ForwardIterator2 first2, ForwardIterator2 last2,
- BinaryPredicate pred);
-</pre></blockquote>
-
-<p>
-However, ForwardIterator1 need not actually be a Forward Iterator; an Input
-Iterator suffices, because we do not need the multi-pass property of the Forward
-Iterator or a true reference.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the declarations of <tt>find_first_of</tt> to:
-</p>
-
-<blockquote><pre>template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2&gt;
- <del>ForwardIterator1</del><ins>InputIterator1</ins>
- find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
- ForwardIterator2 first2, ForwardIterator2 last2);
-template&lt;class <del>ForwardIterator1</del><ins>InputIterator1</ins>, class ForwardIterator2,
- class BinaryPredicate&gt;
-<del>ForwardIterator1</del><ins>InputIterator1</ins>
- find_first_of(<del>ForwardIterator1</del><ins>InputIterator1</ins> first1, <del>ForwardIterator1</del><ins>InputIterator1</ins> last1,
- ForwardIterator2 first2, ForwardIterator2 last2,
- BinaryPredicate pred);
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="577"></a>577. upper_bound(first, last, ...) cannot return last</h3>
-<p><b>Section:</b> 25.3.3.2 [upper.bound] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 2006-05-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-ISO/IEC 14882:2003 says:
-</p>
-
-<blockquote>
-<p>
-25.3.3.2 upper_bound
-</p>
-<p>
-<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
-<tt>[<i>first</i>, <i>last</i>)</tt> such that
-for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
-conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
-</p>
-</blockquote>
-
-<p>
-From the description above, upper_bound cannot return last, since it's
-not in the interval [first, last). This seems to be a typo, because if
-value is greater than or equal to any other values in the range, or if
-the range is empty, returning last seems to be the intended behaviour.
-The corresponding interval for lower_bound is also [first, last].
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change [lib.upper.bound]:
-</p>
-
-<blockquote>
-<p>
-<i>Returns:</i> The furthermost iterator <tt>i</tt> in the range
-<tt>[<i>first</i>, <i>last</i><del>)</del><ins>]</ins></tt> such that
-for any iterator <tt>j</tt> in the range <tt>[<i>first</i>, i)</tt> the following corresponding
-conditions hold: <tt>!(value &lt; *j)</tt> or <tt><i>comp</i>(<i>value</i>, *j) == false</tt>.
-</p>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="578"></a>578. purpose of hint to allocator::allocate()</h3>
-<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The description of the allocator member function
-<code>allocate()</code> requires that the <i>hint</i> argument be
-either 0 or a value previously returned from <code>allocate()</code>.
-Footnote 227 further suggests that containers may pass the address of
-an adjacent element as this argument.
-
- </p>
- <p>
-
-I believe that either the footnote is wrong or the normative
-requirement that the argument be a value previously returned from a
-call to <code>allocate()</code> is wrong. The latter is supported by
-the resolution to issue 20-004 proposed in c++std-lib-3736 by Nathan
-Myers. In addition, the <i>hint</i> is an ordinary void* and not the
-<code>pointer</code> type returned by <code>allocate()</code>, with
-the two types potentially being incompatible and the requirement
-impossible to satisfy.
-
- </p>
- <p>
-
-See also c++std-lib-14323 for some more context on where this came up
-(again).
-
- </p>
-
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-Remove the requirement in 20.6.1.1, p4 that the hint be a value
-previously returned from <code>allocate()</code>. Specifically, change
-the paragraph as follows:
-
- </p>
-<p>
-<del><i>Requires</i>: <i>hint</i> either 0 or previously obtained from member
-<code>allocate</code> and not yet passed to member <code>deallocate</code>.
-The value hint may be used by an implementation to help improve performance
-<sup>223)</sup>.</del> <ins>[<i>Note:</i> The value <i>hint</i> may be used by an
-implementation to help improve performance. -- <i>end note</i>]</ins>
-</p>
-<blockquote><p>
-<del>[Footnote: <sup>223)</sup>In a container member function, the address of an
-adjacent element is often a good choice to pass for this argument.</del>
-</p></blockquote>
-
-
-
-
-<hr>
-<h3><a name="581"></a>581. <code>flush()</code> not unformatted function</h3>
-<p><b>Section:</b> 27.6.2.7 [ostream.unformatted] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.unformatted">issues</a> in [ostream.unformatted].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The resolution of issue 60 changed <code>basic_ostream::flush()</code>
-so as not to require it to behave as an unformatted output function.
-That has at least two in my opinion problematic consequences:
-
- </p>
- <p>
-
-First, <code>flush()</code> now calls <code>rdbuf()-&gt;pubsync()</code>
-unconditionally, without regard to the state of the stream. I can't
-think of any reason why <code>flush()</code> should behave differently
-from the vast majority of stream functions in this respect.
-
- </p>
- <p>
-
-Second, <code>flush()</code> is not required to catch exceptions from
-<code>pubsync()</code> or set <code>badbit</code> in response to such
-events. That doesn't seem right either, as most other stream functions
-do so.
-
- </p>
-
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-I propose to revert the resolution of issue 60 with respect to
-<code>flush()</code>. Specifically, I propose to change 27.6.2.6, p7
-as follows:
-
- </p>
-
-<p>
-Effects: <ins>Behaves as an unformatted output function (as described
-in 27.6.2.6, paragraph 1). </ins>If <code>rdbuf()</code> is not a null
-pointer, <ins>constructs a sentry object. If this object returns
-<code>true</code> when converted to a value of type bool the function
-</ins>calls <code>rdbuf()-&gt;pubsync()</code>. If that function returns
--1 calls <code>setstate(badbit)</code> (which may throw
-<code>ios_base::failure</code> (27.4.4.3)). <ins>Otherwise, if the
-sentry object returns <code>false</code>, does nothing.</ins><del>Does
-not behave as an unformatted output function (as described in
-27.6.2.6, paragraph 1).</del>
-</p>
-
-
-
-<p><i>[
-Kona (2007): Proposed Disposition: Ready
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="586"></a>586. string inserter not a formatted function</h3>
-<p><b>Section:</b> 21.3.8.9 [string.io] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-06-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#string.io">issues</a> in [string.io].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-Section and paragraph numbers in this paper are relative to the
-working draft document number N2009 from 4/21/2006.
-
- </p>
-
- <p>
-
-The <code>basic_string</code> extractor in 21.3.7.9, p1 is clearly
-required to behave as a formatted input function, as is the
-<code>std::getline()</code> overload for string described in p7.
-
- </p>
- <p>
-
-However, the <code>basic_string</code> inserter described in p5 of the
-same section has no such requirement. This has implications on how the
-operator responds to exceptions thrown from <code>xsputn()</code>
-(formatted output functions are required to set <code>badbit</code>
-and swallow the exception unless <code>badbit</code> is also set in
-<code>exceptions()</code>; the string inserter doesn't have any such
-requirement).
-
- </p>
- <p>
-
-I don't see anything in the spec for the string inserter that would
-justify requiring it to treat exceptions differently from all other
-similar operators. (If it did, I think it should be made this explicit
-by saying that the operator "does not behave as a formatted output
-function" as has been made customary by the adoption of the resolution
-of issue 60).
-
- </p>
-
-
- <p><b>Proposed resolution:</b></p>
- <p>
-
-I propose to change the Effects clause in 21.3.7.9, p5, as follows:
-
- </p>
- <blockquote>
- <p>
-
-<i>Effects</i>: <del>Begins by constructing a sentry object k as if k
-were constructed by typename <code>basic_ostream&lt;charT,
-traits&gt;::sentry k (os)</code>. If <code>bool(k)</code> is
-<code>true</code>, </del><ins>Behaves as a formatted output function
-(27.6.2.5.1). After constructing a <code>sentry</code> object, if
-this object returns <code>true</code> when converted to a value of
-type <code>bool</code>, determines padding as described in
-22.2.2.2.2</ins>, then inserts the resulting sequence of characters
-<code><i>seq</i></code> as if by calling <code>os.rdbuf()-&gt;sputn(seq ,
-n)</code>, where <code><i>n</i></code> is the larger of
-<code>os.width()</code> and <code>str.size()</code>; then calls
-<code>os.width(0)</code>. <del>If the call to sputn fails, calls
-<code>os.setstate(ios_base::failbit)</code>.</del>
-
- </p>
- </blockquote>
- <p>
-
-This proposed resilution assumes the resolution of issue 394 (i.e.,
-that all formatted output functions are required to set
-<code>ios_base::badbit</code> in response to any kind of streambuf
-failure), and implicitly assumes that a return value of
-<code>sputn(seq, <i>n</i>)</code> other than <code><i>n</i></code>
-indicates a failure.
-
- </p>
-
-
-
-
-<hr>
-<h3><a name="589"></a>589. Requirements on iterators of member template functions of containers</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2006-08-02</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#536">536</a></p>
-<p><b>Discussion:</b></p>
-<p>
-There appears to be no requirements on the InputIterators used in sequences in 23.1.1 in
-terms of their value_type, and the requirements in 23.1.2 appear to be overly strict
-(requires InputIterator::value_type be the same type as the container's value_type).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 23.1.1 p3:
-</p>
-
-<blockquote><p>
-In Tables 82 and 83, <tt>X</tt> denotes a sequence class, <tt>a</tt> denotes a
-value of <tt>X</tt>, <tt>i</tt> and <tt>j</tt> denote iterators satisfying input
-iterator requirements <ins>and refer to elements <ins>implicitly
-convertible to</ins> <tt>value_type</tt></ins>, <tt>[i, j)</tt> denotes a valid
-range, <tt>n</tt> denotes a value of <tt>X::size_type</tt>, <tt>p</tt> denotes a
-valid iterator to <tt>a</tt>, <tt>q</tt> denotes a valid dereferenceable
-iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range in <tt>a</tt>,
-and <tt>t</tt> denotes a value of <tt>X::value_type</tt>.
-</p></blockquote>
-
-<p>
-Change 23.1.2 p7:
-</p>
-
-<blockquote><p>
-In Table 84, <tt>X</tt> is an associative container class, <tt>a</tt> is a value
-of <tt>X</tt>, <tt>a_uniq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
-unique keys, and <tt>a_eq</tt> is a value of <tt>X</tt> when <tt>X</tt> supports
-multiple keys, <tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and
-refer to elements <del>of</del> <ins>implicitly convertible to</ins>
-<tt>value_type</tt>, <tt>[i, j)</tt> is a valid range, <tt>p</tt> is a valid
-iterator to <tt>a</tt>, <tt>q</tt> is a valid dereferenceable iterator to
-<tt>a</tt>, <tt>[q1, q2)</tt> is a valid range in <tt>a</tt>, <tt>t</tt> is a
-value of <tt>X::value_type</tt>, <tt>k</tt> is a value of <tt>X::key_type</tt>
-and <tt>c</tt> is a value of type <tt>X::key_compare</tt>.
-</p></blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-Concepts will probably come in and rewrite this section anyway. But just in case it is
-easy to fix this up as a safety net and as a clear statement of intent.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="593"></a>593. __STDC_CONSTANT_MACROS</h3>
-<p><b>Section:</b> 18.3 [cstdint], TR1 8.22 [tr.c99.cstdint] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Walter Brown <b>Date:</b> 2006-08-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#cstdint">issues</a> in [cstdint].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
-&lt;cstdint&gt; and &lt;stdint.h&gt;. These are of course based on the C99 header
-&lt;stdint.h&gt;, and were part of TR1.
-</p>
-
-<p>
-Per 18.3.1/1, these headers define a number of macros and function macros.
-While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99
-footnotes do mention __STDC_CONSTANT_MACROS. Further, 18.3.1/2 states that "The
-header defines all ... macros the same as C99 subclause 7.18."
-</p>
-
-<p>
-Therefore, if I wish to have the above-referenced macros and function macros
-defined, must I #define __STDC_CONSTANT_MACROS before I #include &lt;cstdint&gt;, or
-does the C++ header define these macros/function macros unconditionally?
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-To put this issue to rest for C++0X, I propose the following addition to
-18.3.1/2 of the Working Paper N2009:
-</p>
-
-<blockquote><p>
-[Note: The macros defined by &lt;cstdint&gt; are provided unconditionally: in
-particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
-(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note]
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="595"></a>595. TR1/C++0x: fabs(complex&lt;T&gt;) redundant / wrongly specified</h3>
-<p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Stefan Groe Pawig <b>Date:</b> 2006-09-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-TR1 introduced, in the C compatibility chapter, the function
-fabs(complex&lt;T&gt;):
-</p>
-<blockquote><pre>----- SNIP -----
-8.1.1 Synopsis [tr.c99.cmplx.syn]
-
- namespace std {
- namespace tr1 {
-[...]
- template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; x);
- } // namespace tr1
- } // namespace std
-
-[...]
-
-8.1.8 Function fabs [tr.c99.cmplx.fabs]
-
-1 Effects: Behaves the same as C99 function cabs, defined in
- subclause 7.3.8.1.
------ SNIP -----
-</pre></blockquote>
-
-<p>
-The current C++0X draft document (n2009.pdf) adopted this
-definition in chapter 26.3.1 (under the comment // 26.3.7 values)
-and 26.3.7/7.
-</p>
-<p>
-But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
-n1124), the referenced subclause reads
-</p>
-
-<blockquote><pre>----- SNIP -----
-7.3.8.1 The cabs functions
-
- Synopsis
-
-1 #include &lt;complex.h&gt;
- double cabs(double complex z);
- float cabsf(float complex z);
- long double cabsl(long double z);
-
- Description
-
-2 The cabs functions compute the complex absolute value (also called
- norm, modulus, or magnitude) of z.
-
- Returns
-
-3 The cabs functions return the complex absolute value.
------ SNIP -----
-</pre></blockquote>
-
-<p>
-Note that the return type of the cabs*() functions is not a complex
-type. Thus, they are equivalent to the already well established
- template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp; x);
-(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
-document n2009.pdf).
-</p>
-<p>
-So either the return value of fabs() is specified wrongly, or fabs()
-does not behave the same as C99's cabs*().
-</p>
-
-<b>Possible Resolutions</b>
-
-<p>
-This depends on the intention behind the introduction of fabs().
-</p>
-<p>
-If the intention was to provide a /complex/ valued function that
-calculates the magnitude of its argument, this should be
-explicitly specified. In TR1, the categorization under "C
-compatibility" is definitely wrong, since C99 does not provide
-such a complex valued function.
-</p>
-<p>
-Also, it remains questionable if such a complex valued function
-is really needed, since complex&lt;T&gt; supports construction and
-assignment from real valued arguments. There is no difference
-in observable behaviour between
-</p>
-<blockquote><pre> complex&lt;double&gt; x, y;
- y = fabs(x);
- complex&lt;double&gt; z(fabs(x));
-</pre></blockquote>
-<p>
-and
-</p>
-<blockquote><pre> complex&lt;double&gt; x, y;
- y = abs(x);
- complex&lt;double&gt; z(abs(x));
-</pre></blockquote>
-<p>
-If on the other hand the intention was to provide the intended
-functionality of C99, fabs() should be either declared deprecated
-or (for C++0X) removed from the standard, since the functionality
-is already provided by the corresponding overloads of abs().
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Bill believes that abs() is a suitable overload. We should remove fabs().
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change the synopsis in 26.3.1 [complex.synopsis]:
-</p>
-
-<blockquote><pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);</del>
-</pre></blockquote>
-
-<p>
-Remove 26.3.7 [complex.value.ops], p7:
-</p>
-
-<blockquote>
-<pre><del>template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp; <i>x</i>);</del>
-</pre>
-<blockquote>
-<p>
-<del>-7- <i>Effects:</i> Behaves the same as C99 function <tt>cabs</tt>, defined in subclause 7.3.8.1.</del>
-</p>
-</blockquote>
-</blockquote>
-
-
-
-<p><i>[
-Kona (2007): Change the return type of <tt>fabs(complex)</tt> to <tt>T</tt>.
-Proposed Disposition: Ready
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="596"></a>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</h3>
-<p><b>Section:</b> 27.8.1.4 [filebuf.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2006-09-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#filebuf.members">issues</a> in [filebuf.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In testing 27.8.1.4 [filebuf.members], Table 112 (in the latest N2009 draft), we invoke
-</p>
-<blockquote><pre> ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
-</pre></blockquote>
-<p>
-and we expect the open to fail, because out|in|app is not listed in
-Table 92, and just before the table we see very specific words:
-</p>
-<blockquote><p>
- If mode is not some combination of flags shown in the table
- then the open fails.
-</p></blockquote>
-<p>
-But the corresponding table in the C standard, 7.19.5.3, provides two
-modes "a+" and "a+b", to which the C++ modes out|in|app and
-out|in|app|binary would presumably apply.
-</p>
-<p>
-We would like to argue that the intent of Table 112 was to match the
-semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
-unintentional. (Otherwise there would be valid and useful behaviors
-available in C file I/O which are unavailable using C++, for no
-valid functional reason.)
-</p>
-<p>
-We further request that the missing modes be explicitly restored to
-the WP, for inclusion in C++0x.
-</p>
-
-<p><i>[
-Martin adds:
-]</i></p>
-
-
-<p>
-...besides "a+" and "a+b" the C++ table is also missing a row
-for a lone app bit which in at least two current implementation
-as well as in Classic Iostreams corresponds to the C stdio "a"
-mode and has been traditionally documented as implying ios::out.
-Which means the table should also have a row for in|app meaning
-the same thing as "a+" already proposed in the issue.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to the table "File open modes" in 27.8.1.4 [filebuf.members]:
-</p>
-
-<blockquote>
-<table border="1">
-<caption> File open modes</caption>
-<tbody><tr>
-<th colspan="5"><tt>ios_base</tt> Flag combination</th>
-<th><tt>stdio</tt> equivalent</th>
-</tr>
-<tr>
-<th><tt>binary</tt></th><th><tt>in</tt></th><th><tt>out</tt></th><th><tt>trunc</tt></th><th><tt>app</tt></th><th><tt>&nbsp;</tt></th>
-</tr>
-
-<tr>
-<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"a"</tt></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a"</tt></ins></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w"</tt></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r"</tt></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+"</tt></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+"</tt></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
-</tr>
-<tr>
-<td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+"</tt></ins></td>
-</tr>
-
-<tr>
-<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
-</tr>
-<tr>
-<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>"ab"</tt></td>
-</tr>
-<tr>
-<td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"ab"</tt></ins></td>
-</tr>
-<tr>
-<td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"wb"</tt></td>
-</tr>
-<tr>
-<td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"rb"</tt></td>
-</tr>
-<tr>
-<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><tt>"r+b"</tt></td>
-</tr>
-<tr>
-<td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td><tt>+</tt></td> <td>&nbsp;</td> <td><tt>"w+b"</tt></td>
-</tr><tr>
-<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
-</tr>
-<tr>
-<td><ins><tt>+</tt></ins></td> <td><ins><tt>+</tt></ins></td> <td>&nbsp;</td> <td>&nbsp;</td> <td><ins><tt>+</tt></ins></td> <td><ins><tt>"a+b"</tt></ins></td>
-</tr>
-
-
-</tbody></table>
-</blockquote>
-
-
-
-<p><i>[
-Kona (2007) Added proposed wording and moved to Review.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="598"></a>598. Decimal: Conversion to integral should truncate, not round.</h3>
-<p><b>Section:</b> TRDecimal 3.2 [trdec.types.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#trdec.types.types">active issues</a> in [trdec.types.types].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types.types">issues</a> in [trdec.types.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
-<p><b>Discussion:</b></p>
-
-<p>
-In a private email, Daniel writes:
-</p>
-<blockquote>
-<p>
-I would like to
-ask, what where the reason for the decision to
-define the semantics of the integral conversion of the decimal types, namely
-</p>
-<pre>"operator long long() const;
-
- Returns: Returns the result of the
-conversion of *this to the type long long, as if
-performed by the expression llrounddXX(*this)."
-</pre>
-<p>
-where XX stands for either 32, 64, or 128,
-corresponding to the proper decimal type. The
-exact meaning of llrounddXX is not given in that
-paper, so I compared it to the corresponding
-definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
-</p>
-<p>
-"The lround and llround functions round their
-argument to the nearest integer value,
-rounding halfway cases away from zero, regardless
-of the current rounding direction. [..]"
-</p>
-<p>
-Now considering the fact that integral conversion
-of the usual floating-point types ("4.9
-Floating-integral conversions") has truncation
-semantic I wonder why this conversion behaviour
-has not been transferred for the decimal types.
-</p>
-</blockquote>
-<p>
-Robert comments:
-</p>
-<p>
-Also, there is a further error in the <b>Returns:</b> clause for converting <code>decimal::decimal128</code> to <code>long long</code>. It currently calls <code>llroundd64</code>, not <code>llroundd128</code>.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the <b>Returns:</b> clause in 3.2.2.4 to:
-</p>
-<blockquote><p>
-<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd32(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
-</p></blockquote>
-<p>
-Change the <b>Returns:</b> clause in 3.2.3.4 to:
-</p>
-<blockquote><p>
-<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
-</p></blockquote>
-<p>
-Change the <b>Returns:</b> clause in 3.2.4.4 to:
-</p>
-<blockquote><p>
-<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
-</p></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="599"></a>599. Decimal: Say "octets" instead of "bytes."</h3>
-<p><b>Section:</b> TRDecimal 3.1 [trdec.types.encodings] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Daniel writes in a private email:
-</p>
-
-<blockquote>
-<p>
-- 3.1 'Decimal type encodings' says in its note:
-</p>
-<pre>"this implies that
-sizeof(std::decimal::decimal32) == 4,
-sizeof(std::decimal::decimal64) == 8, and
-sizeof(std::decimal::decimal128) == 16."
-</pre>
-<p>
-This is a wrong assertion, because the definition
-of 'byte' in 1.7 'The C+ + memory model' of ISO
-14882 (2nd edition) does not specify that a byte
-must be necessarily 8 bits large, which would be
-necessary to compare with the specified bit sizes
-of the types decimal32, decimal64, and decimal128.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 3.1 as follows:
-</p>
-<blockquote>
-<p>
-The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
-</p>
-<ul>
-<li>
-decimal32 is a <em>decimal32</em> number, which is encoded in four consecutive <del>bytes</del> <ins>octets</ins> (32 bits)
-</li>
-<li>
-decimal64 is a <em>decimal64</em> number, which is encoded in eight consecutive <del>bytes</del> <ins>octets</ins> (64 bits)
-
-</li>
-<li>
-decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive <del>bytes</del> <ins>octets</ins> (128 bits)
-</li>
-</ul>
-<p>
-<del>[<i>Note:</i> this implies that <code>sizeof(std::decimal::decimal32) == 4</code>, <code>sizeof(std::decimal::decimal64) == 8</code>, and <code>sizeof(std::decimal::decimal128) == 16</code>. <i>--end note</i>]</del>
-</p>
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="600"></a>600. Decimal: Wrong parameters for wcstod* functions</h3>
-<p><b>Section:</b> TRDecimal 3.9 [trdec.types.cwchar] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Daniel writes:
-</p>
-<blockquote><p>
-- 3.9.1 'Additions to &lt;cwchar&gt;' provides wrong
-signatures to the wcstod32, wcstod64, and
-wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
-</p></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change "3.9.1 Additions to <code>&lt;cwchar&gt;</code> synopsis" to:
-</p>
-<pre> namespace std {
- namespace decimal {
- // 3.9.2 wcstod functions:
- decimal32 wcstod32 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
- decimal64 wcstod64 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
- decimal128 wcstod128 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
- }
- }
-</pre>
-
-
-
-
-<hr>
-<h3><a name="601"></a>601. Decimal: numeric_limits typos</h3>
-<p><b>Section:</b> TRDecimal 3.3 [trdec.types.limits] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Daniel writes in a private email:
-</p>
-
-<blockquote>
-<p>
-- 3.3 'Additions to header &lt;limits&gt;' contains two
-errors in the specialisation of numeric_limits&lt;decimal::decimal128&gt;:
-</p>
-<ol>
-<li>The static member max() returns DEC128_MIN, this should be DEC128_MAX.</li>
-<li>The static member digits is assigned to 384,
-this should be 34 (Probably mixed up with the
-max. exponent for decimal::decimal64).</li>
-</ol>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In "3.3 Additions to header <code>&lt;limits&gt;</code>" change numeric_limits&lt;decimal::decimal128&gt; as follows:
-</p>
-<pre> template&lt;&gt; class numeric_limits&lt;decimal::decimal128&gt; {
- public:
- static const bool is_specialized = true;
-
- static decimal::decimal128 min() throw() { return DEC128_MIN; }
- static decimal::decimal128 max() throw() { return <del>DEC128_MIN;</del> <ins>DEC128_MAX;</ins> }
-
- static const int digits = <del>384</del> <ins>34</ins>;
- /* ... */
-</pre>
-
-
-
-
-<hr>
-<h3><a name="602"></a>602. Decimal: "generic floating type" not defined.</h3>
-<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Daniel Krugler <b>Date:</b> 2006-05-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The document uses the term "generic floating types," but defines it nowhere.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the first paragraph of "3 Decimal floating-point types" as follows:
-</p>
-<blockquote><p>
-This Technical Report introduces three decimal floating-point types, named
-decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
-subset of the set of values of type decimal64; the set of values of the type
-decimal64 is a subset of the set of values of the type decimal128. Support for
-decimal128 is optional. <ins>These types supplement the Standard C++ types
-<code>float</code>, <code>double</code>, and <code>long double</code>, which are
-collectively described as the <i>basic floating types</i></ins>.
-</p></blockquote>
-
-
-
-
-<hr>
-<h3><a name="603"></a>603. Decimal: Trivially simplifying decimal classes.</h3>
-<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>In c++std-lib-17198, Martin writes:</p>
-
-<blockquote><p>
-Each of the three classes proposed in the paper (decimal32, decimal64,
-and decimal128) explicitly declares and specifies the semantics of its
-copy constructor, copy assignment operator, and destructor. Since the
-semantics of all three functions are identical to the trivial versions
-implicitly generated by the compiler in the absence of any declarations
-it is safe to drop them from the spec. This change would make the
-proposed classes consistent with other similar classes already in the
-standard (e.g., std::complex).
-</p></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change "3.2.2 Class <code>decimal32</code>" as follows:
-</p>
-<pre> namespace std {
- namespace decimal {
- class decimal32 {
- public:
- // 3.2.2.1 construct/copy/destroy:
- decimal32();
- <del>decimal32(const decimal32 &amp; d32);</del>
- <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
- <del>~decimal32();</del>
- /* ... */
-</pre>
-<p>
-Change "3.2.2.1 construct/copy/destroy" as follows:
-</p>
-<pre> decimal32();
-
- Effects: Constructs an object of type decimal32 with the value 0;
-
- <del>decimal32(const decimal32 &amp; d32);</del>
- <del>decimal32 &amp; operator=(const decimal32 &amp; d32);</del>
-
- <del>Effects: Copies an object of type decimal32.</del>
-
- <del>~decimal32();</del>
-
- <del>Effects: Destroys an object of type decimal32.</del>
-
-</pre>
-<p>
-Change "3.2.3 Class <code>decimal64</code>" as follows:
-</p>
-<pre> namespace std {
- namespace decimal {
- class decimal64 {
- public:
- // 3.2.3.1 construct/copy/destroy:
- decimal64();
- <del>decimal64(const decimal64 &amp; d64);</del>
- <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
- <del>~decimal64();</del>
- /* ... */
-</pre>
-<p>
-Change "3.2.3.1 construct/copy/destroy" as follows:
-</p>
-<pre> decimal64();
-
- Effects: Constructs an object of type decimal64 with the value 0;
-
- <del>decimal64(const decimal64 &amp; d64);</del>
- <del>decimal64 &amp; operator=(const decimal64 &amp; d64);</del>
-
- <del>Effects: Copies an object of type decimal64.</del>
-
- <del>~decimal64();</del>
-
- <del>Effects: Destroys an object of type decimal64.</del>
-
-</pre>
-<p>
-Change "3.2.4 Class <code>decimal128</code>" as follows:
-</p>
-<pre> namespace std {
- namespace decimal {
- class decimal128 {
- public:
- // 3.2.4.1 construct/copy/destroy:
- decimal128();
- <del>decimal128(const decimal128 &amp; d128);</del>
- <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
- <del>~decimal128();</del>
- /* ... */
-</pre>
-<p>
-Change "3.2.4.1 construct/copy/destroy" as follows:
-</p>
-<pre> decimal128();
-
- Effects: Constructs an object of type decimal128 with the value 0;
-
- <del>decimal128(const decimal128 &amp; d128);</del>
- <del>decimal128 &amp; operator=(const decimal128 &amp; d128);</del>
-
- <del>Effects: Copies an object of type decimal128.</del>
-
- <del>~decimal128();</del>
-
- <del>Effects: Destroys an object of type decimal128.</del>
-
-</pre>
-
-
-
-
-<hr>
-<h3><a name="604"></a>604. Decimal: Storing a reference to a facet unsafe.</h3>
-<p><b>Section:</b> TRDecimal 3 [trdec.types] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2006-05-28</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#trdec.types">issues</a> in [trdec.types].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In c++std-lib-17197, Martin writes:
-</p>
-<blockquote><p>
-The extended_num_get and extended_num_put facets are designed
-to store a reference to a num_get or num_put facet which the
-extended facets delegate the parsing and formatting of types
-other than decimal. One form of the extended facet's ctor (the
-default ctor and the size_t overload) obtains the reference
-from the global C++ locale while the other form takes this
-reference as an argument.
-</p></blockquote>
-<blockquote><p>
-The problem with storing a reference to a facet in another
-object (as opposed to storing the locale object in which the
-facet is installed) is that doing so bypasses the reference
-counting mechanism designed to prevent a facet that is still
-being referenced (i.e., one that is still installed in some
-locale) from being destroyed when another locale that contains
-it is destroyed. Separating a facet reference from the locale
-it comes from van make it cumbersome (and in some cases might
-even make it impossible) for programs to prevent invalidating
-the reference. (The danger of this design is highlighted in
-the paper.)
-</p></blockquote>
-<blockquote><p>
-This problem could be easily avoided by having the extended
-facets store a copy of the locale from which they would extract
-the base facet either at construction time or when needed. To
-make it possible, the forms of ctors of the extended facets that
-take a reference to the base facet would need to be changed to
-take a locale argument instead.
-</p></blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-1. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows:
-</p>
-<pre> extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
-
- /* ... */
-
- <del>// <i>const std::num_get&lt;charT, InputIterator&gt; &amp; <b>base</b></i>; <i><b>exposition only</b></i></del>
- <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins>
-</pre>
-<p>
-2. Change the description of the above constructor in 3.10.2.1:
-</p>
-<pre> extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
-
-</pre>
-<blockquote>
-<p>
-<b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by:
-</p>
-<pre> extended_num_get(const <del>std::num_get&lt;charT, InputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
- : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
- { /* ... */ }
-
-</pre>
-<p>
-<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_get</code> facet.</del>
-</p>
-</blockquote>
-<p>
-3. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &amp;, ios_base::iostate &amp;, bool &amp;) const</code>, <i>et al</i> to
-</p>
-<blockquote><p>
-<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_get&lt;charT, InputIterator&gt; &gt;(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>.
-</p></blockquote>
-<p>
-4. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows:
-</p>
-<pre> extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
-
- /* ... */
-
- <del>// <i>const std::num_put&lt;charT, OutputIterator&gt; &amp; <b>base</b></i>; <i><b>exposition only</b></i></del>
- <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins>
-</pre>
-<p>
-5. Change the description of the above constructor in 3.10.3.1:
-</p>
-<pre> extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0);
-</pre>
-<blockquote>
-<p>
-<b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by:
-</p>
-<pre> extended_num_put(const <del>std::num_put&lt;charT, OutputIterator&gt;</del> <ins>std::locale</ins> &amp; <i>b</i>, size_t <i>refs</i> = 0)
- : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
- { /* ... */ }
-
-</pre>
-<p>
-<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_put</code> facet.</del>
-</p>
-</blockquote>
-<p>
-6. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &amp;, char_type, bool &amp;) const</code>, <i>et al</i> to
-</p>
-<blockquote><p>
-<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet&lt;std::num_put&lt;charT, OutputIterator&gt; &gt;(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>.
-</p></blockquote>
-
-<p><i>[
-Redmond: We would prefer to rename "extended" to "decimal".
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="605"></a>605. Decimal: &lt;decfloat.h&gt; doesn't live here anymore.</h3>
-<p><b>Section:</b> TRDecimal 3.4 [trdec.types.cdecfloat] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TRDec">TRDec</a>
- <b>Submitter:</b> Robert Klarer <b>Date:</b> 2006-10-17</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#TRDec">TRDec</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In Berlin, WG14 decided to drop the &lt;decfloat.h&gt; header. The
-contents of that header have been moved into &lt;float.h&gt;. For the
-sake of C compatibility, we should make corresponding changes.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-1. Change the heading of subclause 3.4, "Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code>" to "Additions to headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code>."
-</p>
-<p>
-2. Change the text of subclause 3.4 as follows:
-</p>
-<blockquote>
-<p>
-<del>The standard C++ headers <code>&lt;cfloat&gt;</code> and <code>&lt;float.h&gt;</code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>. Their contents remain unchanged by this Technical Report.</del>
-</p>
-<p>
-<del>Headers <code>&lt;cdecfloat&gt;</code> and <code>&lt;decfloat.h&gt;</code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code>&lt;decfloat.h&gt;</code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
-</p>
-<p>
-<ins>The header <code>&lt;cfloat&gt;</code> is described in [tr.c99.cfloat]. The header <code>&lt;float.h&gt;</code>
-is described in [tr.c99.floath]. These headers are extended by this
-Technical Report to define characteristics of the decimal
-floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code>&lt;float.h&gt;</code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins>
-</p>
-</blockquote>
-<p>
-3. Change the heading of subclause 3.4.1, "Header <code>&lt;cdecfloat&gt;</code> synopsis" to "Additions to header <code>&lt;cfloat&gt;</code> synopsis."
-</p>
-<p>
-4. Change the heading of subclause 3.4.2, "Header <code>&lt;decfloat.h&gt;</code> synopsis" to "Additions to header <code>&lt;float.h&gt;</code> synopsis."
-</p>
-<p>
-5. Change the contents of 3.4.2 as follows:
-</p>
-<pre> <del>#include &lt;cdecfloat&gt;</del>
-
- // <i>C-compatibility convenience typedefs:</i>
-
- typedef std::decimal::decimal32 _Decimal32;
- typedef std::decimal::decimal64 _Decimal64;
- typedef std::decimal::decimal128 _Decimal128;
-</pre>
-
-
-
-
-
-<hr>
-<h3><a name="607"></a>607. Concern about short seed vectors</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Short seed vectors of 32-bit quantities all result in different states. However
-this is not true of seed vectors of 16-bit (or smaller) quantities. For example
-these two seeds
-</p>
-
-<blockquote><pre>unsigned short seed = {1, 2, 3};
-unsigned short seed = {1, 2, 3, 0};
-</pre></blockquote>
-
-<p>
-both pack to
-</p>
-
-<blockquote><pre>unsigned seed = {0x20001, 0x3};
-</pre></blockquote>
-
-<p>
-yielding the same state.
-</p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
-</p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="608"></a>608. Unclear seed_seq construction details</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2006-10-26</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
-treatment of signed quantities is unclear. Better to spell it out.
-</p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
-</p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="609"></a>609. missing static const</h3>
-<p><b>Section:</b> 26.4.4.2 [rand.adapt.ibits], TR1 5.1 [tr.rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Walter E. Brown <b>Date:</b> 2006-11-02</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In preparing N2111, an error on my part resulted in the omission of the
-following line from the template synopsis in the cited section:
-</p>
-
-<blockquote><pre>static const size_t word_size = w;
-</pre></blockquote>
-
-<p>
-(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
-</p>
-
-<blockquote><pre>// engine characteristics
-<ins>static const size_t word_size = w;</ins>
-</pre></blockquote>
-
-<p>
-and accept my apologies for the oversight.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="610"></a>610. Suggested non-normative note for C++0x</h3>
-<p><b>Section:</b> 20.6.15.2.1 [func.wrap.func.con], TR1 3.7.2.1 [tr.func.wrap.func.con] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Scott Meyers <b>Date:</b> 2006-11-02</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-My suggestion is that implementers of both tr1::function and its
-official C++0x successor be explicitly encouraged (but not required) to
-optimize for the cases mentioned above, i.e., function pointers and
-small function objects. They could do this by using a small internal
-buffer akin to the buffer used by implementations of the small string
-optimization. (That would make this the small functor optimization --
-SFO :-}) The form of this encouragement could be a note in the standard
-akin to footnote 214 of the current standard.
-</p>
-
-<p>
-Dave Abrahams notes:
-</p>
-
-<p>
-"shall not throw exceptions" should really be "nothing," both to be more
-grammatical and to be consistent with existing wording in the standard.
-</p>
-
-<p>
-Doug Gregor comments: I think this is a good idea. Currently, implementations of
-tr1::function are required to have non-throwing constructors and assignment
-operators when the target function object is a function pointer or a
-reference_wrapper. The common case, however, is for a tr1::function to store
-either an empty function object or a member pointer + an object pointer.
-</p>
-<p>
-The function implementation in the upcoming Boost 1.34.0 uses the
-"SFO", so that the function objects for typical bind expressions like
-</p>
-<blockquote><pre>bind(&amp;X::f, this, _1, _2, _3)
-</pre></blockquote>
-
-<p>
-do not require heap allocation when stored in a boost::function. I
-believe Dinkumware's implementation also performs this optimization.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
-</p>
-
-<blockquote>
-<p>
-<i>Throws:</i> shall not throw exceptions if <tt>f</tt>'s target is a function
-pointer or a function object passed via <tt>reference_wrapper</tt>. Otherwise,
-may throw <tt>bad_alloc</tt> or any exception thrown by the copy constructor of
-the stored function object.
-</p>
-<p>
-<ins><i>Note:</i> Implementations are encouraged to avoid the use of dynamically
-allocated memory for "small" function objects, e.g., where <tt>f</tt>'s target
-is an object holding only a pointer or reference to an object and a member
-function pointer (a "bound member function").</ins>
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="611"></a>611. Standard library templates and incomplete types</h3>
-<p><b>Section:</b> 17.4.3.7 [res.on.functions] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Nicola Musatti <b>Date:</b> 2006-11-13</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In the latest available draft standard
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf">N2134</a>)
- 17.4.3.6 [res.on.functions] states:
-</p>
-
-<blockquote>
-<p>
--1- In certain cases (replacement functions, handler functions, operations on
-types used to instantiate standard library template components), the C++
-Standard Library depends on components supplied by a C++ program. If these
-components do not meet their requirements, the Standard places no requirements
-on the implementation.
-</p>
-
-<p>
--2- In particular, the effects are undefined in the following cases:
-</p>
-<p>
-[...]
-</p>
-<ul>
-<li>if an incomplete type (3.9) is used as a template argument when
-instantiating a template component. </li>
-</ul>
-</blockquote>
-
-<p>
-This is contradicted by 20.6.6.2/2 [util.smartptr.shared] which
-states:
-</p>
-
-<blockquote>
-<p>
-[...]
-</p>
-
-<p>
-The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Modify the last bullet of 17.4.3.6/2 [res.on.functions] to allow for
-exceptions:
-</p>
-
-<blockquote>
-<ul>
-<li>if an incomplete type (3.9) is used as a template argument when
-instantiating a template component<ins>, unless specifically allowed for the
-component</ins>. </li>
-</ul>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="612"></a>612. numeric_limits::is_modulo insufficiently defined</h3>
-<p><b>Section:</b> 18.2.1.2 [numeric.limits.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Chris Jefferson <b>Date:</b> 2006-11-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.limits.members">issues</a> in [numeric.limits.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-18.2.1.2 55 states that "A type is modulo if it is possible to add two
-positive numbers together and have a result that wraps around to a
-third number that is less".
-This seems insufficient for the following reasons:
-</p>
-
-<ol>
-<li>Doesn't define what that value received is.</li>
-<li>Doesn't state the result is repeatable</li>
-<li> Doesn't require that doing addition, subtraction and other
-operations on all values is defined behaviour.</li>
-</ol>
-
-<p><i>[
-Batavia: Related to
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2144.pdf">N2144</a>.
-Pete: is there an ISO definition of modulo? Underflow on signed behavior is undefined.
-]</i></p>
-
-
-<p><i>[
-Bellevue: accept resolution, move to ready status.
-Does this mandate that is_modulo be true on platforms for which int
-happens to b modulo? A: the standard already seems to require that.
-]</i></p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Suggest 18.2.1.2 [numeric.limits.members], paragraph 57 is amended to:
-</p>
-
-<blockquote><p>
-A type is modulo if<ins>,</ins> <del>it is possible to add two positive numbers
-and have a result that wraps around to a third number that is less.</del>
-<ins>given any operation involving +,- or * on values of that type whose value
-would fall outside the range <tt>[min(), max()]</tt>, then the value returned
-differs from the true value by an integer multiple of <tt>(max() - min() +
-1)</tt>.</ins>
-</p></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="613"></a>613. max_digits10 missing from numeric_limits</h3>
-<p><b>Section:</b> 18.2.1.5 [numeric.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-11-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numeric.special">issues</a> in [numeric.special].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 18.2.1.5 [numeric.special] starts out by saying that "All members shall be provided
-for all specializations."
-</p>
-<p>
-Then it goes on to show specializations for float and bool, where one member
-is missing (max_digits10).
-</p>
-
-<p>
-Maarten Kronenburg adds:
-</p>
-
-<p>
-I agree, just adding the comment that the exact number of decimal digits
-is digits * ln(radix) / ln(10), where probably this real number is
-rounded downward for digits10, and rounded upward for max_digits10
-(when radix=10, then digits10=max_digits10).
-Why not add this exact definition also to the standard, so the user
-knows what these numbers exactly mean.
-</p>
-
-<p>
-Howard adds:
-</p>
-
-<p>
-For reference, here are the correct formulas from
-<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1822.pdf">N1822</a>:
-</p>
-
-<blockquote><pre>digits10 = floor((digits-1) * log10(2))
-max_digits10 = ceil((1 + digits) * log10(2))
-</pre></blockquote>
-
-<p>
-We are also missing a statement regarding for what specializations this member has meaning.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change and add after 18.2.1.2 [numeric.limits.members], p11:
-</p>
-
-<blockquote>
-<pre>static const int max_digits10;</pre>
-<blockquote>
-<p>
--11- Number of base 10 digits required to ensure that values which
-differ <del>by only one epsilon</del> are always differentiated.
-</p>
-<p><ins>
--12- Meaningful for all floating point types.
-</ins></p>
-</blockquote>
-</blockquote>
-
-<p>
-Change 18.2.1.5 [numeric.special], p2:
-</p>
-
-<blockquote><pre>template&lt;&gt; class numeric_limits&lt;float&gt; {
-public:
- static const bool is_specialized = true;
- ...
- static const int digits10 = 6;
- <ins>static const int max_digits10 = 9</ins>;
- ...
-</pre></blockquote>
-
-<p>
-Change 18.2.1.5 [numeric.special], p3:
-</p>
-
-<blockquote><pre>template&lt;&gt; class numeric_limits&lt;bool&gt; {
-public:
- static const bool is_specialized = true;
- ...
- static const int digits10 = 0;
- <ins>static const int max_digits10 = 0</ins>;
- ...
-</pre></blockquote>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="616"></a>616. missing 'typename' in ctype_byname</h3>
-<p><b>Section:</b> 22.2.1.2 [locale.ctype.byname] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2006-12-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.ctype.byname">issues</a> in [locale.ctype.byname].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 22.2.1.2 defines the ctype_byname class template. It contains the
-line
-</p>
-
-<blockquote><pre>typedef ctype&lt;charT&gt;::mask mask;
-</pre></blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-as this is a dependent type, it should obviously be
-</p>
-
-<blockquote><pre>typedef <ins>typename</ins> ctype&lt;charT&gt;::mask mask;
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="618"></a>618. valarray::cshift() effects on empty array</h3>
-<p><b>Section:</b> 26.5.2.7 [valarray.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 2007-01-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I would respectfully request an issue be opened with the intention to
-clarify the wording for <tt>size() == 0</tt> for <tt>cshift</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.5.2.7 [valarray.members], paragraph 10:
-</p>
-
-<blockquote>
-
-<pre>valarray&lt;T&gt; cshift(int <i>n</i>) const;
-</pre>
-
-<blockquote>
-<p>
-This function returns an object of class <tt>valarray&lt;T&gt;</tt>, of
-length <tt>size()</tt>, <del>each of whose elements <tt>I</tt> is
-<tt>(*this)[(I + n ) % size()]</tt>. Thus, if element zero is taken as
-the leftmost element, a positive value of <i>n</i> shifts the elements
-circularly left <i>n</i> places.</del> <ins>that is a circular shift of <tt>*this</tt>. If
-element zero is taken as the leftmost element, a non-negative value of
-<i>n</i> shifts the elements circularly left <i>n</i> places and a
-negative value of <i>n</i> shifts the elements circularly right
--<i>n</i> places.</ins>
-</p>
-</blockquote>
-</blockquote>
-
-
-
-<p><b>Rationale:</b></p>
-<p>
-We do not believe that there is any real ambiguity about what happens
-when <tt>size() == 0</tt>, but we do believe that spelling this out as a C++
-expression causes more trouble that it solves. The expression is
-certainly wrong when <tt>n &lt; 0</tt>, since the sign of % with negative arguments
-is implementation defined.
-</p>
-
-
-<p><i>[
-Kona (2007) Changed proposed wording, added rationale and set to Review.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="619"></a>619. Longjmp wording problem</h3>
-<p><b>Section:</b> 18.9 [support.runtime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2007-01-12</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The wording for <tt>longjmp</tt> is confusing.
-</p>
-<p>
-18.9 [support.runtime] -4- Other runtime support
-</p>
-<blockquote><p>
-The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more restricted
-behavior in this International Standard. If any automatic objects would
-be destroyed by a thrown exception transferring control to another
-(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt> that
-the throw point that transfers control to the same (destination) point has
-undefined behavior.
-</p></blockquote>
-<p>
-Someone at Google thinks that should say "then a call to <tt>longjmp(jbuf, val)</tt>
-*at* the throw point that transfers control".
-</p>
-<p>
-Bill Gibbons thinks it should say something like "If any automatic objects
-would be destroyed by an exception thrown at the point of the longjmp and
-caught only at the point of the setjmp, the behavior is undefined."
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In general, accept Bill Gibbons' recommendation,
-but add "call" to indicate that the undefined behavior
-comes from the dynamic call, not from its presence in the code.
-In 18.9 [support.runtime] paragraph 4, change
-</p>
-
-<blockquote><p>
-The function signature <tt>longjmp(jmp_buf jbuf, int val)</tt> has more
-restricted behavior in this International Standard. <del>If any automatic
-objects would be destroyed by a thrown exception transferring control to another
-(destination) point in the program, then a call to <tt>longjmp(jbuf, val)</tt>
-that the throw point that transfers control to the same (destination) point has
-undefined behavior.</del> <ins>A <tt>setjmp</tt>/<tt>longjmp</tt> call pair has
-undefined behavior if replacing the <tt>setjmp</tt> and <tt>longjmp</tt> by
-<tt>catch</tt> and <tt>throw</tt> would destroy any automatic objects.</ins>
-</p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="620"></a>620. valid uses of empty valarrays</h3>
-<p><b>Section:</b> 26.5.2.1 [valarray.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#valarray.cons">active issues</a> in [valarray.cons].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#valarray.cons">issues</a> in [valarray.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The <i>Effects</i> clause for the default <code>valarray</code> ctor
-suggests that it is possible to increase the size of an empty
-<code>valarray</code> object by calling other non-const member
-functions of the class besides <code>resize()</code>. However, such an
-interpretation would be contradicted by the requirement on the copy
-assignment operator (and apparently also that on the computed
-assignments) that the assigned arrays be the same size. See the
-reflector discussion starting with c++std-lib-17871.
-
- </p>
- <p>
-
-In addition, <i>Footnote</i> 280 uses some questionable normative
-language.
-
- </p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-Reword the <i>Effects</i> clause and <i>Footnote 280</i> as follows (26.5.2.1 [valarray.cons]):
-
- </p>
- <blockquote>
- <p>
-
-<code>valarray();</code>
-
- </p>
- <p>
-
-<i>Effects</i>: Constructs an object of class
-<code>valarray&lt;T&gt;</code>,<sup>279)</sup> which has zero
-length<del> until it is passed into a library function as a modifiable
-lvalue or through a non-constant this pointer</del>.<sup>280)</sup>
-
- </p>
- <p>
-
-<ins><i>Postcondition</i>: <code>size() == 0</code>.</ins>
-
- </p>
- <p>
-
-<i>Footnote 280</i>: This default constructor is essential, since
-arrays of <code>valarray</code> <del>are likely to prove useful.
-There shall also be a way to change the size of an array after
-initialization; this is supplied by the semantics</del> <ins>may be
-useful. The length of an empty array can be increased after
-initialization by means</ins> of the <code>resize()</code> member
-function.
-
- </p>
- </blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="621"></a>621. non-const copy assignment operators of helper arrays</h3>
-<p><b>Section:</b> 26.5 [numarray] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#numarray">issues</a> in [numarray].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The computed and "fill" assignment operators of <code>valarray</code>
-helper array class templates (<code>slice_array</code>,
-<code>gslice_array</code>, <code>mask_array</code>, and
-<code>indirect_array</code>) are const member functions of each class
-template (the latter by the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#123">123</a>
-since they have reference semantics and thus do not affect
-the state of the object on which they are called. However, the copy
-assignment operators of these class templates, which also have
-reference semantics, are non-const. The absence of constness opens
-the door to speculation about whether they really are intended to have
-reference semantics (existing implementations vary widely).
-
- </p>
-
-<p>
-Pre-Kona, Martin adds:
-</p>
-
-<p>
-I realized that adding the const qualifier to the
-functions as I suggested would break the const correctness of the
-classes. A few possible solutions come to mind:
-</p>
-
-<ol>
-<li>Add the const qualifier to the return types of these functions.</li>
-<li>Change the return type of all the functions to void to match
-the signatures of all the other assignment operators these classes
-define.</li>
-<li>Prohibit the copy assignment of these classes by declaring the
-copy assignment operators private (as is done and documented by
-some implementations).</li>
-</ol>
-
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-Declare the copy assignment operators of all four helper array
-class templates const.
-
- </p>
- <p>
-
-Specifically, make the following edits:
-
- </p>
- <p>
-
-Change the signature in 26.5.5 [template.slice.array] and
-26.5.5.1 [slice.arr.assign] as follows:
-
- </p>
- <blockquote><pre>
-<code><ins>const</ins> slice_array&amp; operator= (const slice_array&amp;)<ins> const</ins>;</code>
-
- </pre></blockquote>
- <p>
-
-Change the signature in 26.5.7 [template.gslice.array] and
-26.5.7.1 [gslice.array.assign] as follows:
-
- </p>
- <blockquote><pre>
-<code><ins>const</ins> gslice_array&amp; operator= (const gslice_array&amp;)<ins> const</ins>;</code>
-
- </pre></blockquote>
- <p>
-
-Change the signature in 26.5.8 [template.mask.array] and 26.5.8.1 [mask.array.assign] as
-follows:
-
- </p>
- <blockquote><pre>
-<code><ins>const</ins> mask_array&amp; operator= (const mask_array&amp;)<ins> const</ins>;</code>
-
- </pre></blockquote>
- <p>
-
-Change the signature in 26.5.9 [template.indirect.array] and
-26.5.9.1 [indirect.array.assign] as follows:
-
- </p>
- <blockquote><pre>
-<code><ins>const</ins> indirect_array&amp; operator= (const indirect_array&amp;)<ins> const</ins>;</code>
-
- </pre></blockquote>
-
-
-<p><i>[
-Kona (2007) Added const qualification to the return types and set to Ready.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="622"></a>622. behavior of <code>filebuf</code> dtor and <code>close</code> on error</h3>
-<p><b>Section:</b> 27.8.1.17 [fstream.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-<code>basic_filebuf</code> dtor is specified to have the following
-straightforward effects:
-
- </p>
- <blockquote><p>
-
-<i>Effects</i>: Destroys an object of class
-<code>basic_filebuf</code>. Calls <code>close()</code>.
-
- </p></blockquote>
- <p>
-
-<code>close()</code> does a lot of potentially complicated processing,
-including calling <code>overflow()</code> to write out the termination
-sequence (to bring the output sequence to its initial shift
-state). Since any of the functions called during the processing can
-throw an exception, what should the effects of an exception be on the
-dtor? Should the dtor catch and swallow it or should it propagate it
-to the caller? The text doesn't seem to provide any guidance in this
-regard other than the general restriction on throwing (but not
-propagating) exceptions from destructors of library classes in
-17.4.4.9 [res.on.exception.handling].
-
- </p>
- <p>
-
-Further, the last thing <code>close()</code> is specified to do is
-call <code>fclose()</code> to close the <code>FILE</code> pointer. The
-last sentence of the <i>Effects</i> clause reads:
-
- </p>
- <blockquote><p>
-
-... If any of the calls to <code>overflow</code> or
-<code>std::fclose</code> fails then <code>close</code> fails.
-
- </p></blockquote>
- <p>
-
-This suggests that <code>close()</code> might be required to call
-<code>fclose()</code> if and only if none of the calls to
-<code>overflow()</code> fails, and avoid closing the <code>FILE</code>
-otherwise. This way, if <code>overflow()</code> failed to flush out
-the data, the caller would have the opportunity to try to flush it
-again (perhaps after trying to deal with whatever problem may have
-caused the failure), rather than losing it outright.
-
- </p>
- <p>
-
-On the other hand, the function's <i>Postcondition</i> specifies that
-<code>is_open() == false</code>, which suggests that it should call
-<code>fclose()</code> unconditionally. However, since
-<i>Postcondition</i> clauses are specified for many functions in the
-standard, including constructors where they obviously cannot apply
-after an exception, it's not clear whether this <i>Postcondition</i>
-clause is intended to apply even after an exception.
-
- </p>
- <p>
-
-It might be worth noting that the traditional behavior (Classic
-Iostreams <code>fstream::close()</code> and C <code>fclose()</code>)
-is to close the <code>FILE</code> unconditionally, regardless of
-errors.
-
- </p>
-
-<p><i>[
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#397">397</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#418">418</a> for related issues.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-After discussing this on the reflector (see the thread starting with
-c++std-lib-17650) we propose that <code>close()</code> be clarified to
-match the traditional behavior, that is to close the <code>FILE</code>
-unconditionally, even after errors or exceptions. In addition, we
-propose the dtor description be amended so as to explicitly require it
-to catch and swallow any exceptions thrown by <code>close()</code>.
-
- </p>
- <p>
-
-Specifically, we propose to make the following edits in
-27.8.1.4 [filebuf.members]:
-
- </p>
- <blockquote>
- <pre>
-<code>basic_filebuf&lt;charT,traits&gt;* close();</code>
-
- </pre>
- <p>
-
-<i>Effects</i>: If <code>is_open() == false</code>, returns a null
-pointer. If a put area exists, calls
-<code>overflow(traits::eof())</code> to flush characters. If the last
-virtual member function called on <code>*this</code> (between
-<code>underflow</code>, <code>overflow</code>, <code>seekoff</code>,
-and <code>seekpos</code>) was <code>overflow</code> then calls
-<code>a_codecvt.unshift</code> (possibly several times) to determine a
-termination sequence, inserts those characters and calls
-<code>overflow(traits::eof())</code> again. Finally<ins>, regardless
-of whether any of the preceding calls fails or throws an exception,
-the function</ins> <del>it</del> closes the file ("as if" by calling
-<code>std::fclose(file)</code>).<sup>334)</sup> If any of the calls
-<ins>made by the function</ins><del>to <code>overflow</code>
-or</del><ins>, including </ins><code>std::fclose</code><ins>, </ins>
-fails then <code>close</code> fails<ins> by returning a null pointer.
-If one of these calls throws an exception, the exception is caught and
-rethrown after closing the file.</ins>
-
- </p>
- </blockquote>
- <p>
-
-And to make the following edits in 27.8.1.2 [filebuf.cons].
-
- </p>
- <blockquote>
- <pre>
-<code>virtual ~basic_filebuf();</code>
-
- </pre>
- <p>
-
-<i>Effects</i>: Destroys an object of class
-<code>basic_filebuf&lt;charT,traits&gt;</code>. Calls
-<code>close()</code>. <ins>If an exception occurs during the
-destruction of the object, including the call to <code>close()</code>,
-the exception is caught but not rethrown (see
-17.4.4.9 [res.on.exception.handling]).</ins>
-
- </p>
- </blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="623"></a>623. <code>pubimbue</code> forbidden to call <code>imbue</code></h3>
-<p><b>Section:</b> 27.1.1 [iostream.limits.imbue] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-27.1.1 [iostream.limits.imbue] specifies that "no function described in
-clause 27 except for <code>ios_base::imbue</code> causes any instance
-of <code>basic_ios::imbue</code> or
-<code>basic_streambuf::imbue</code> to be called."
-
- </p>
- <p>
-
-That contradicts the <i>Effects</i> clause for
-<code>basic_streambuf::pubimbue()</code> which requires the function
-to do just that: call <code>basic_streambuf::imbue()</code>.
-
- </p>
-
-
-<p><b>Proposed resolution:</b></p>
- <p>
-
-To fix this, rephrase the sentence above to allow
-<code>pubimbue</code> to do what it was designed to do. Specifically.
-change 27.1.1 [iostream.limits.imbue], p1 to read:
-
- </p>
- <blockquote><p>
-
-No function described in clause 27 except for
-<code>ios_base::imbue</code> <ins>and <code>basic_filebuf::pubimbue</code></ins>
-causes any instance of <code>basic_ios::imbue</code> or
-<code>basic_streambuf::imbue</code> to be called. ...
-
- </p></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="624"></a>624. <code>valarray</code> assignment and arrays of unequal length</h3>
-<p><b>Section:</b> 26.5.2.2 [valarray.assign] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-01-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
- <p>
-
-The behavior of the <code>valarray</code> copy assignment operator is
-defined only when both sides have the same number of elements and the
-spec is explicit about assignments of arrays of unequal lengths having
-undefined behavior.
-
- </p>
- <p>
-
-However, the generalized subscripting assignment operators overloaded
-on <code>slice_array</code> et al (26.5.2.2 [valarray.assign]) don't have any
-such restriction, leading the reader to believe that the behavior of
-these overloads is well defined regardless of the lengths of the
-arguments.
-
- </p>
- <p>
-
-For example, based on the reading of the spec the behavior of the
-snippet below can be expected to be well-defined:
-
- </p>
- <pre> const std::slice from_0_to_3 (0, 3, 1); // refers to elements 0, 1, 2
- const std::valarray&lt;int&gt; a (1, 3); // a = { 1, 1, 1 }
- std::valarray&lt;int&gt; b (2, 4); // b = { 2, 2, 2, 2 }
-
- b = a [from_0_to_3];
- </pre>
- <p>
-
-In practice, <code>b</code> may end up being <code>{ 1, 1, 1 }</code>,
-<code>{ 1, 1, 1, 2 }</code>, or anything else, indicating that
-existing implementations vary.
-
- </p>
-
-<p>
-Quoting from Section 3.4, Assignment operators, of Al Vermeulen's
-Proposal for Standard C++ Array Classes (see c++std-lib-704;
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0308.asc">N0308</a>):
-</p>
-<blockquote><p>
- ...if the size of the array on the right hand side of the equal
- sign differs from the size of the array on the left, a run time
- error occurs. How this error is handled is implementation
- dependent; for compilers which support it, throwing an exception
- would be reasonable.
-</p></blockquote>
-
-<p>
-And see more history in
-<a href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1993/N0280.pdf">N0280</a>.
-</p>
-
- <p>
-
-It has been argued in discussions on the committee's reflector that
-the semantics of all <code>valarray</code> assignment operators should
-be permitted to be undefined unless the length of the arrays being
-assigned is the same as the length of the one being assigned from. See
-the thread starting at c++std-lib-17786.
-
- </p>
- <p>
-
-In order to reflect such views, the standard must specify that the
-size of the array referred to by the argument of the assignment must
-match the size of the array under assignment, for example by adding a
-<i>Requires</i> clause to 26.5.2.2 [valarray.assign] as follows:
-
- </p>
- <blockquote><p>
-
-<i>Requires</i>: The length of the array to which the argument refers
-equals <code>size()</code>.
-
- </p></blockquote>
-
- <p>
-
-Note that it's far from clear that such leeway is necessary in order
-to implement <code>valarray</code> efficiently.
-
- </p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Insert new paragraph into 26.5.2.2 [valarray.assign]:
-</p>
-
-<blockquote>
-<pre>valarray&lt;T&gt;&amp; operator=(const slice_array&lt;T&gt;&amp;);
-valarray&lt;T&gt;&amp; operator=(const gslice_array&lt;T&gt;&amp;);
-valarray&lt;T&gt;&amp; operator=(const mask_array&lt;T&gt;&amp;);
-valarray&lt;T&gt;&amp; operator=(const indirect_array&lt;T&gt;&amp;);
-</pre>
-<blockquote>
-<p><ins>
-<i>Requires</i>: The length of the array to which the argument refers
-equals <code>size()</code>.
-</ins></p>
-<p>
-These operators allow the results of a generalized subscripting operation to be assigned directly to a <tt>valarray</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="628"></a>628. Inconsistent definition of basic_regex constructor</h3>
-<p><b>Section:</b> 28.8 [re.regex] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-01-23</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.regex">issues</a> in [re.regex].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 28.8 [re.regex] lists a constructor
-</p>
-
-<blockquote><pre>template&lt;class InputIterator&gt;
-basic_regex(InputIterator first, InputIterator last,
- flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
-
-<p>
-However, in section 28.8.2 [re.regex.construct], this constructor takes a
-pair of <tt>ForwardIterator</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 28.8.2 [re.regex.construct]:
-</p>
-
-<blockquote><pre>template &lt;class <del>ForwardIterator</del> <ins>InputIterator</ins>&gt;
- basic_regex(<del>ForwardIterator</del> <ins>InputIterator</ins> first, <del>ForwardIterator</del> <ins>InputIterator</ins> last,
- flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="634"></a>634. <tt>allocator.address()</tt> doesn't work for types overloading <tt>operator&amp;</tt></h3>
-<p><b>Section:</b> 20.7.5.1 [allocator.members] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-02-07</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a></p>
-<p><b>Discussion:</b></p>
-
-<p>
-20.7.5.1 [allocator.members] says:
-</p>
-<blockquote>
-<pre>pointer address(reference <i>x</i>) const;</pre>
-<blockquote>
-<p>
--1- <i>Returns:</i> <tt>&amp;<i>x</i></tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-20.7.5.1 [allocator.members] defines <tt>CopyConstructible</tt> which currently not
-only defines the semantics of copy construction, but also restricts what an overloaded
-<tt>operator&amp;</tt> may do. I believe proposals are in the works (such as concepts
-and rvalue reference) to decouple these two requirements. Indeed it is not evident
-that we should disallow overloading <tt>operator&amp;</tt> to return something other
-than the address of <tt>*this</tt>.
-</p>
-
-<p>
-An example of when you want to overload <tt>operator&amp;</tt> to return something
-other than the object's address is proxy references such as <tt>vector&lt;bool&gt;</tt>
-(or its replacement, currently code-named <tt>bit_vector</tt>). Taking the address of
-such a proxy reference should logically yield a proxy pointer, which when dereferenced,
-yields a copy of the original proxy reference again.
-</p>
-
-<p>
-On the other hand, some code truly needs the address of an object, and not a proxy
-(typically for determining the identity of an object compared to a reference object).
-<a href="http://www.boost.org/">boost</a> has long recognized this dilemma and solved it with
-<a href="http://www.boost.org/libs/utility/utility.htm#addressof"><tt>boost::addressof</tt></a>.
-It appears to me that this would be useful functionality for the default allocator. Adopting
-this definition for <tt>allocator::address</tt> would free the standard of requiring
-anything special from types which overload <tt>operator&amp;</tt>. Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#580">580</a>
-is expected to make use of <tt>allocator::address</tt> mandatory for containers.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.7.5.1 [allocator.members]:
-</p>
-
-<blockquote>
-<pre>pointer address(reference <i>x</i>) const;</pre>
-<blockquote>
-<p>
--1- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
-even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
-</p>
-</blockquote>
-
-<pre>const_pointer address(address(const_reference <i>x</i>) const;</pre>
-<blockquote>
-<p>
--2- <i>Returns:</i> <del><tt>&amp;<i>x</i></tt>.</del> <ins>The actual address of object referenced by <i>x</i>,
-even in the presence of an overloaded <tt>operator&amp;</tt>.</ins>
-</p>
-</blockquote>
-</blockquote>
-
-<p><i>[
-post Oxford: This would be rendered NAD Editorial by acceptance of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
-]</i></p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which
-was subsequently split out into a separate paper N2436 for the purposes of voting.
-The resolution in N2436 addresses this issue. The LWG voted to accelerate this
-issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="638"></a>638. deque end invalidation during erase</h3>
-<p><b>Section:</b> 23.2.2.3 [deque.modifiers] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Steve LoBasso <b>Date:</b> 2007-02-17</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The standard states at 23.2.2.3 [deque.modifiers]/4:
-</p>
-<blockquote><pre>deque erase(...)
-</pre>
- <p>
-<i>Effects:</i> ... An erase at either end of the deque invalidates only
-the iterators and the references to the erased elements.
-</p>
-</blockquote>
-<p>
-This does not state that iterators to end will be invalidated.
-It needs to be amended in such a way as to account for end invalidation.
-</p>
-<p>
-Something like:
-</p>
-<blockquote><p>
-Any time the last element is erased, iterators to end are invalidated.
-</p></blockquote>
-
-<p>
-This would handle situations like:
-</p>
-<blockquote><pre>erase(begin(), end())
-erase(end() - 1)
-pop_back()
-resize(n, ...) where n &lt; size()
-pop_front() with size() == 1
-
-</pre></blockquote>
-
-<p><i>[
-Post Kona, Steve LoBasso notes:
-]</i></p>
-
-
-<blockquote>
-My only issue with the proposed resolution is that it might not be clear
-that <tt>pop_front()</tt> [where <tt>size() == 1</tt>] can invalidate past-the-end
-iterators.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 23.2.2.3 [deque.modifiers], p4:
-</p>
-
-<blockquote>
-<pre>iterator erase(const_iterator position);
-iterator erase(const_iterator first, const_iterator last);
-</pre>
-
-<blockquote>
-<p>
--4- <i>Effects:</i> An erase in the middle of the <tt>deque</tt>
-invalidates all the iterators and references to elements of the
-<tt>deque</tt> <ins>and the past-the-end iterator</ins>. An erase at
-either end of the <tt>deque</tt> invalidates only the iterators and the
-references to the erased elements<ins>, except that erasing at the end
-also invalidates the past-the-end iterator</ins>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-<p><i>[
-Kona (2007): Proposed wording added and moved to Review.
-]</i></p>
-
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Note that there is existing code that relies on iterators not being
-invalidated, but there are also existing implementations that do
-invalidate iterators. Thus, such code is not portable in any case. There
-is a pop_front() note, which should possibly be a separate issue. Mike
-Spertus to evaluate and, if need be, file an issue.
-</blockquote>
-
-
-
-
-<hr>
-<h3><a name="640"></a>640. 27.6.2.5.2 does not handle (unsigned) long long</h3>
-<p><b>Section:</b> 27.6.2.6.2 [ostream.inserters.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-02-17</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#ostream.inserters.arithmetic">issues</a> in [ostream.inserters.arithmetic].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The arithmetic inserters are described in 27.6.2.6.2 [ostream.inserters.arithmetic].
-Although the section starts with a listing of the inserters including
-the new ones:
-</p>
-
-<blockquote><pre>operator&lt;&lt;(long long val );
-operator&lt;&lt;(unsigned long long val );
-</pre></blockquote>
-
-<p>
-the text in paragraph 1, which describes the corresponding effects
-of the inserters, depending on the actual type of val, does not
-handle the types <tt>long long</tt> and <tt>unsigned long long</tt>.
-</p>
-
-<p><i>[
-Alisdair: In addition to the (unsigned) long long problem, that whole paragraph
-misses any reference to extended integral types supplied by the
-implementation - one of the additions by core a couple of working papers
-back.
-]</i></p>
-
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.6.2.6.2 [ostream.inserters.arithmetic]/1 change the third sentence
-</p>
-
-<blockquote>
-When val is of type <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
-long</tt>, <ins>long long, unsigned long long,</ins> <tt>double</tt>,
-<tt>long double</tt>, or <tt>const void*</tt>, the formatting conversion
-occurs as if it performed the following code fragment:
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="643"></a>643. Impossible "as if" clauses</h3>
-<p><b>Section:</b> 27.8.1.1 [filebuf], 22.2.2.2.2 [facet.num.put.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-02-20</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The current standard 14882:2003(E) as well as N2134 have the
-following
-defects:
-</p>
-
-<p>
-27.8.1.1 [filebuf]/5 says:
-</p>
-
-<blockquote>
-<p>
-In order to support file I/O and multibyte/wide character conversion, conversions are performed using members of a
-facet, referred to as <tt><i>a_codecvt</i></tt> in following sections, obtained "as if" by
-</p>
-<blockquote><pre>codecvt&lt;charT,char,typename traits::state_type&gt; <i>a_codecvt</i> =
- use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
-</pre></blockquote>
-</blockquote>
-
-<p>
-<tt>use_facet</tt> returns a <tt>const facet</tt> reference and no facet is
-copyconstructible, so the codecvt construction should fail to compile.
-</p>
-
-<p>
-A similar issue arises in 22.2.2.2.2 [facet.num.put.virtuals]/15 for <tt>num_punct</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 27.8.1.1 [filebuf]/5 change the "as if" code
-</p>
-
-<blockquote><pre><ins>const </ins>codecvt&lt;charT,char,typename traits::state_type&gt;<ins>&amp;</ins> <i>a_codecvt</i> =
- use_facet&lt;codecvt&lt;charT,char,typename traits::state_type&gt; &gt;(getloc());
-</pre></blockquote>
-
-<p>
-In 22.2.2.2.2 [facet.num.put.virtuals]/15 (This is para 5 in N2134) change
-</p>
-
-<blockquote>
-<p>
-A local variable <tt><i>punct</i></tt> is initialized via
-</p>
-<blockquote><pre><ins>const </ins>numpunct&lt;charT&gt;<ins>&amp;</ins> <i>punct</i> = use_facet&lt; numpunct&lt;charT&gt; &gt;(<i>str</i>.getloc() )<ins>;</ins>
-</pre></blockquote>
-</blockquote>
-
-<p>
-(Please note also the additional provided trailing semicolon)
-</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="646"></a>646. const incorrect match_result members</h3>
-<p><b>Section:</b> 28.10.4 [re.results.form] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-02-26</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-28.10.4 [re.results.form] (root and para 3) in N2134 defines the two function template
-members format as non-const functions, although they are declared
-as const in 28.10 [re.results]/3.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the missing <tt>const</tt> specifier to both <tt>format</tt> overloads described
-in section 28.10.4 [re.results.form].
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="650"></a>650. regex_token_iterator and const correctness</h3>
-<p><b>Section:</b> 28.12.2 [re.tokiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-03-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter">issues</a> in [re.tokiter].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Both the class definition of regex_token_iterator (28.12.2
-[re.tokiter]/6) and the latter member specifications (28.12.2.2
-[re.tokiter.comp]/1+2) declare both comparison operators as
-non-const functions. Furtheron, both dereference operators are
-unexpectedly also declared as non-const in 28.12.2 [re.tokiter]/6
-as well as in (28.12.2.3 [re.tokiter.deref]/1+2).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-1) In (28.12.2 [re.tokiter]/6) change the current declarations
-</p>
-
-<blockquote><pre>bool operator==(const regex_token_iterator&amp;) <ins>const</ins>;
-bool operator!=(const regex_token_iterator&amp;) <ins>const</ins>;
-const value_type&amp; operator*() <ins>const</ins>;
-const value_type* operator-&gt;() <ins>const</ins>;
-</pre></blockquote>
-
-<p>
-2) In 28.12.2.2 [re.tokiter.comp] change the following declarations
-</p>
-
-<blockquote><pre>bool operator==(const regex_token_iterator&amp; right) <ins>const</ins>;
-bool operator!=(const regex_token_iterator&amp; right) <ins>const</ins>;
-</pre></blockquote>
-
-<p>
-3) In 28.12.2.3 [re.tokiter.deref] change the following declarations
-</p>
-
-<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
-const value_type* operator-&gt;() <ins>const</ins>;
-</pre></blockquote>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
-is to adopt the proposed wording in this issue).
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="651"></a>651. Missing preconditions for regex_token_iterator c'tors</h3>
-<p><b>Section:</b> 28.12.2.1 [re.tokiter.cnstr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-03-05</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#re.tokiter.cnstr">issues</a> in [re.tokiter.cnstr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The text provided in 28.12.2.1 [re.tokiter.cnstr]/2+3 describes
-the effects of the three non-default constructors of class
-template regex_token_iterator but is does not clarify which values
-are legal values for submatch/submatches. This becomes
-an issue, if one takes 28.12.2 [re.tokiter]/9 into account, which explains
-the notion of a "current match" by saying:
-</p>
-
-<blockquote><p>
-The <i>current match</i> is <tt>(*position).prefix()</tt> if <tt>subs[N]
-== -1</tt>, or <tt>(*position)[subs[N]]</tt> for any other value of
-<tt>subs[N]</tt>.
-</p></blockquote>
-
-<p>
-It's not clear to me, whether other negative values except -1
-are legal arguments or not - it seems they are not.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following precondition paragraph just before the current
-28.12.2.1 [re.tokiter.cnstr]/2:
-</p>
-
-<blockquote><p>
-<i>Requires:</i> Each of the initialization values of <tt>subs</tt> must be <tt>&gt;= -1</tt>.
-</p></blockquote>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
-is to adopt the proposed wording in this issue).
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="652"></a>652. regex_iterator and const correctness</h3>
-<p><b>Section:</b> 28.12.1 [re.regiter] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-03-05</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Both the class definition of regex_iterator (28.12.1 [re.regiter]/1)
-and the latter member specification (28.12.1.2 [re.regiter.comp]/1+2)
-declare both comparison operators as
-non-const functions. Furtheron, both dereference operators are
-unexpectedly also declared as non-const in 28.12.1 [re.regiter]/1
-as well as in (28.12.1.3 [re.regiter.deref]/1+2).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-1) In (28.12.1 [re.regiter]/1) change the current declarations
-</p>
-
-<blockquote><pre>bool operator==(const regex_iterator&amp;) <ins>const</ins>;
-bool operator!=(const regex_iterator&amp;) <ins>const</ins>;
-const value_type&amp; operator*() <ins>const</ins>;
-const value_type* operator-&gt;() <ins>const</ins>;
-</pre></blockquote>
-
-<p>
-2) In 28.12.1.3 [re.regiter.deref] change the following declarations
-</p>
-
-<blockquote><pre>const value_type&amp; operator*() <ins>const</ins>;
-const value_type* operator-&gt;() <ins>const</ins>;
-</pre></blockquote>
-
-<p>
-3) In 28.12.1.2 [re.regiter.comp] change the following declarations
-</p>
-
-<blockquote><pre>bool operator==(const regex_iterator&amp; right) <ins>const</ins>;
-bool operator!=(const regex_iterator&amp; right) <ins>const</ins>;
-</pre></blockquote>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue (which
-is to adopt the proposed wording in this issue).
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="654"></a>654. Missing IO roundtrip for random number engines</h3>
-<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-03-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Table 98 and para 5 in 26.4.1.3 [rand.req.eng] specify
-the IO insertion and extraction semantic of random
-number engines. It can be shown, v.i., that the specification
-of the extractor cannot guarantee to fulfill the requirement
-from para 5:
-</p>
-
-<blockquote><p>
-If a textual representation written via os &lt;&lt; x was
-subsequently read via is &gt;&gt; v, then x == v provided that
-there have been no intervening invocations of x or of v.
-</p></blockquote>
-
-<p>
-The problem is, that the extraction process described in
-table 98 misses to specify that it will initially set the
-if.fmtflags to ios_base::dec, see table 104:
-</p>
-
-<blockquote><p>
-dec: converts integer input or generates integer output
-in decimal base
-</p></blockquote>
-
-<p>
-Proof: The following small program demonstrates the violation
-of requirements (exception safety not fulfilled):
-</p>
-
-<blockquote><pre>#include &lt;cassert&gt;
-#include &lt;ostream&gt;
-#include &lt;iostream&gt;
-#include &lt;iomanip&gt;
-#include &lt;sstream&gt;
-
-class RanNumEngine {
- int state;
-public:
- RanNumEngine() : state(42) {}
-
- bool operator==(RanNumEngine other) const {
- return state == other.state;
- }
-
- template &lt;typename Ch, typename Tr&gt;
- friend std::basic_ostream&lt;Ch, Tr&gt;&amp; operator&lt;&lt;(std::basic_ostream&lt;Ch, Tr&gt;&amp; os, RanNumEngine engine) {
- Ch old = os.fill(os.widen(' ')); // Sets space character
- std::ios_base::fmtflags f = os.flags();
- os &lt;&lt; std::dec &lt;&lt; std::left &lt;&lt; engine.state; // Adds ios_base::dec|ios_base::left
- os.fill(old); // Undo
- os.flags(f);
- return os;
- }
-
- template &lt;typename Ch, typename Tr&gt;
- friend std::basic_istream&lt;Ch, Tr&gt;&amp; operator&gt;&gt;(std::basic_istream&lt;Ch, Tr&gt;&amp; is, RanNumEngine&amp; engine) {
- // Uncomment only for the fix.
-
- //std::ios_base::fmtflags f = is.flags();
- //is &gt;&gt; std::dec;
- is &gt;&gt; engine.state;
- //is.flags(f);
- return is;
- }
-};
-
-int main() {
- std::stringstream s;
- s &lt;&lt; std::setfill('#'); // No problem
- s &lt;&lt; std::oct; // Yikes!
- // Here starts para 5 requirements:
- RanNumEngine x;
- s &lt;&lt; x;
- RanNumEngine v;
- s &gt;&gt; v;
- assert(x == v); // Fails: 42 == 34
-}
-</pre></blockquote>
-
-<p>
-A second, minor issue seems to be, that the insertion
-description from table 98 unnecessarily requires the
-addition of ios_base::fixed (which only influences floating-point
-numbers). Its not entirely clear to me whether the proposed
-standard does require that the state of random number engines
-is stored in integral types or not, but I have the impression
-that this is the indent, see e.g. p. 3
-</p>
-
-<blockquote><p>
-The specification of each random number engine defines the
-size of its state in multiples of the size of its result_type.
-</p></blockquote>
-
-<p>
-If other types than integrals are supported, then I wonder why
-no requirements are specified for the precision of the stream.
-</p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
-</p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="655"></a>655. Signature of generate_canonical not useful</h3>
-<p><b>Section:</b> 26.4.7.2 [rand.util.canonical] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-03-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.canonical">issues</a> in [rand.util.canonical].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 26.4.2 [rand.synopsis] we have the declaration
-</p>
-
-<blockquote><pre>template&lt;class RealType, class UniformRandomNumberGenerator,
- size_t bits&gt;
-result_type generate_canonical(UniformRandomNumberGenerator&amp; g);
-</pre></blockquote>
-
-<p>
-Besides the "result_type" issue (already recognized by Bo Persson
-at Sun, 11 Feb 2007 05:26:47 GMT in this group) it's clear, that
-the template parameter order is not reasonably choosen: Obviously
-one always needs to specify all three parameters, although usually
-only two are required, namely the result type RealType and the
-wanted bits, because UniformRandomNumberGenerator can usually
-be deduced.
-</p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
-</p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="660"></a>660. Missing Bitwise Operations</h3>
-<p><b>Section:</b> 20.6 [function.objects] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-04-02</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#function.objects">issues</a> in [function.objects].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>Section 20.6 [function.objects] provides <span id="st" name="st" class="st">function</span>
-<span id="st" name="st" class="st">objects</span> for some unary and binary
-operations, but others are missing. In a LWG reflector discussion, beginning
-with c++std-lib-18078, pros and cons of adding some of the missing operations
-were discussed. Bjarne Stroustrup commented "Why standardize what isn't used?
-Yes, I see the chicken and egg problems here, but it would be nice to see a
-couple of genuine uses before making additions."</p>
-<p>A number of libraries, including Rogue Wave, GNU, Adobe ASL, and Boost, have
-already added these functions, either publicly or for internal use. For example,
-Doug Gregor commented: "Boost will also add ... (|, &amp;, ^) in 1.35.0, because we
-need those <span id="st" name="st" class="st">function</span>
-<span id="st" name="st" class="st">objects</span> to represent various parallel
-collective operations (reductions, prefix reductions, etc.) in the new Message
-Passing Interface (MPI) library."</p>
-<p>Because the bitwise operators have the strongest use cases, the proposed
-resolution is limited to them.</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>To 20.6 [function.objects], Function objects, paragraph 2, add to the header
-&lt;functional&gt; synopsis:</p>
-<blockquote>
- <pre>template &lt;class T&gt; struct bit_and;
-template &lt;class T&gt; struct bit_or;
-template &lt;class T&gt; struct bit_xor;</pre>
-</blockquote>
-<p>At a location in clause 20 to be determined by the Project Editor, add:</p>
-<blockquote>
- <p>The library provides basic function object classes for all of the bitwise
- operators in the language ([expr.bit.and], [expr.or], [exp.xor]).</p>
- <pre>template &lt;class T&gt; struct bit_and : binary_function&lt;T,T,T&gt; {
- T operator()(const T&amp; x , const T&amp; y ) const;
-};</pre>
- <blockquote>
- <p><code>operator()</code> returns<code> x &amp; y</code> .</p>
- </blockquote>
- <pre>template &lt;class T&gt; struct bit_or : binary_function&lt;T,T,T&gt; {
- T operator()(const T&amp; x , const T&amp; y ) const;
-};</pre>
- <blockquote>
- <p><code>operator()</code> returns <code>x | y</code> .</p>
- </blockquote>
- <pre>template &lt;class T&gt; struct bit_xor : binary_function&lt;T,T,T&gt; {
- T operator()(const T&amp; x , const T&amp; y ) const;
-};</pre>
- <blockquote>
- <p><code>operator()</code> returns <code>x ^ y</code> .</p>
- </blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="661"></a>661. New 27.6.1.2.2 changes make special extractions useless</h3>
-<p><b>Section:</b> 27.6.1.2.2 [istream.formatted.arithmetic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-04-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#istream.formatted.arithmetic">issues</a> in [istream.formatted.arithmetic].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-To the more drastic changes of 27.6.1.2.2 [istream.formatted.arithmetic] in the current draft N2134 belong
-the explicit description of the extraction of the types short and int in
-terms of as-if code fragments.
-</p>
-
-<ol>
-<li>
-The corresponding as-if extractions in paragraph 2 and 3 will never
-result in a change of the operator&gt;&gt; argument val, because the
-contents of the local variable lval is in no case written into val.
-Furtheron both fragments need a currently missing parentheses in the
-beginning of the if-statement to be valid C++.
-</li>
-<li>I would like to ask whether the omission of a similar explicit
-extraction of unsigned short and unsigned int in terms of long -
-compared to their corresponding new insertions, as described in
-27.6.2.6.2 [ostream.inserters.arithmetic], is a deliberate decision or
-an
-oversight.
-</li>
-</ol>
-
-
-<p><b>Proposed resolution:</b></p>
-<ol>
-<li>
-<p>
-In 27.6.1.2.2 [istream.formatted.arithmetic]/2 change the current as-if code fragment
-</p>
-<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
-iostate err = 0;
-long lval;
-use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
-if (err == 0) <ins>{</ins>
- <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval)<del>)</del>
- err = ios_base::failbit;
- <ins>else
- val = static_cast&lt;short&gt;(lval);
-}</ins>
-setstate(err);
-</pre></blockquote>
-
-<p>
-Similarily in 27.6.1.2.2 [istream.formatted.arithmetic]/3 change the current as-if fragment
-</p>
-
-<blockquote><pre>typedef num_get&lt;charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
-iostate err = 0;
-long lval;
-use_facet&lt;numget&gt;(loc).get(*this, 0, *this, err, lval );
-if (err == 0) <ins>{</ins>
- <del>&amp;&amp;</del> <ins>if</ins> (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval)<del>)</del>
- err = ios_base::failbit;
- <ins>else
- val = static_cast&lt;int&gt;(lval);
-}</ins>
-setstate(err);
-</pre></blockquote>
-</li>
-<li>
----
-</li>
-</ol>
-
-
-<p><i>[
-Kona (2007): Note to the editor: the name lval in the call to <tt>use_facet</tt>
-is incorrectly italicized in the code fragments corresponding to
-<tt>operator&gt;&gt;(short &amp;)</tt> and <tt>operator &gt;&gt;(int &amp;)</tt>. Also, val -- which appears
-twice on the line with the <tt>static_cast</tt> in the proposed resolution --
-should be italicized. Also, in response to part two of the issue: this
-is deliberate.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="664"></a>664. <tt>do_unshift</tt> for <tt>codecvt&lt;char, char, mbstate_t&gt;</tt></h3>
-<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-22.2.1.4.2 [locale.codecvt.virtuals], para 7 says (regarding <tt>do_unshift</tt>):
-</p>
-
-<blockquote><p>
-<i>Effects:</i> Places characters starting at to that should be appended to
-terminate a sequence when the current <tt>stateT</tt> is given by
-<tt><i>state</i></tt>.<sup>237)</sup> Stores no more than <tt>(<i>to_limit</i> -
-<i>to</i>)</tt> destination elements, and leaves the <tt><i>to_next</i></tt>
-pointer pointing one beyond the last element successfully stored.
-<em><tt>codecvt&lt;char, char, mbstate_t&gt;</tt> stores no characters.</em>
-</p></blockquote>
-
-<p>
-The following objection has been raised:
-</p>
-
-<blockquote><p>
-Since the C++ Standard permits a nontrivial conversion for the required
-instantiations of <tt>codecvt</tt>, it is overly restrictive to say that
-<tt>do_unshift</tt> must store no characters and return <tt>noconv</tt>.
-</p></blockquote>
-
-<p>
-[Plum ref _222152Y50]
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 22.2.1.4.2 [locale.codecvt.virtuals], p7:
-</p>
-
-<blockquote>
-<p>
-<i>Effects:</i> Places characters starting at <i>to</i> that should be
-appended to terminate a sequence when the current <tt>stateT</tt> is
-given by state.<sup>237)</sup> Stores no more than (<i>to_limit -to</i>)
-destination elements, and leaves the <i>to_next</i> pointer pointing one
-beyond the last element successfully stored. <del><tt>codecvt&lt;char, char,
-mbstate_t&gt;</tt> stores no characters.</del>
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="665"></a>665. <tt>do_unshift</tt> return value</h3>
-<p><b>Section:</b> 22.2.1.4.2 [locale.codecvt.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.codecvt.virtuals">issues</a> in [locale.codecvt.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-22.2.1.4.2 [locale.codecvt.virtuals], para 8 says:
-</p>
-
-<blockquote><p>
-<tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.
-</p></blockquote>
-
-<p>
-The following objection has been raised:
-</p>
-
-<blockquote><p>
-Despite what the C++ Standard
-says, <tt>unshift</tt> can't always return <tt>noconv</tt> for the default facets, since
-they can be nontrivial. At least one implementation does whatever the
-C functions do.
-</p></blockquote>
-
-<p>
-[Plum ref _222152Y62]
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 22.2.1.4.2 [locale.codecvt.virtuals], p8:
-</p>
-
-<blockquote>
-<p><i>Returns:</i> An enumeration value, as summarized in Table 76:</p>
-<p>...</p>
-<p>
-<del><tt>codecvt&lt;char,char,mbstate_t&gt;</tt>, returns <tt>noconv</tt>.</del>
-</p>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="666"></a>666. <tt>moneypunct::do_curr_symbol()</tt></h3>
-<p><b>Section:</b> 22.2.6.3.2 [locale.moneypunct.virtuals] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thomas Plum <b>Date:</b> 2007-04-16</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#locale.moneypunct.virtuals">issues</a> in [locale.moneypunct.virtuals].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-22.2.6.3.2 [locale.moneypunct.virtuals], para 4 footnote 257 says
-</p>
-
-<blockquote><p>
-<sup>257)</sup> For international
-specializations (second template parameter <tt>true</tt>) this is always four
-characters long, usually three letters and a space.
-</p></blockquote>
-
-<p>
-The following objection has been raised:
-</p>
-
-<blockquote><p>
-The international currency
-symbol is whatever the underlying locale says it is, not necessarily
-four characters long.
-</p></blockquote>
-
-<p>
-[Plum ref _222632Y41]
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change footnote 253 in 22.2.6.3.2 [locale.moneypunct.virtuals]:
-</p>
-
-<blockquote>
-<p>
-<sup>253)</sup> For international specializations (second template
-parameter <tt>true</tt>) this is <del>always</del> <ins>typically</ins>
-four characters long, usually three letters and a space.
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="672"></a>672. Swappable requirements need updating</h3>
-<p><b>Section:</b> 20.1.1 [utility.arg.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#utility.arg.requirements">active issues</a> in [utility.arg.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#utility.arg.requirements">issues</a> in [utility.arg.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The current <tt>Swappable</tt> is:
-</p>
-
-<blockquote>
-<table border="1">
-<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
-<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
-<tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td><td><tt>t</tt> has the value originally held by <tt>u</tt>, and <tt>u</tt> has the value originally
-held by <tt>t</tt></td></tr>
-<tr><td colspan="3">
-<p>
-The Swappable requirement is met by satisfying one or more of the following conditions:
-</p>
-<ul>
-<li>
-<tt>T</tt> is Swappable if <tt>T</tt> satisfies the <tt>CopyConstructible</tt> requirements (Table 34)
-and the <tt>CopyAssignable</tt> requirements (Table 36);
-</li>
-<li>
-<tt>T</tt> is Swappable if a namespace scope function named <tt>swap</tt> exists in the same
-namespace as the definition of <tt>T</tt>, such that the expression <tt>swap(t,u)</tt> is valid
-and has the semantics described in this table.
-</li>
-</ul>
-</td></tr>
-</tbody></table>
-</blockquote>
-
-<p>
-With the passage of rvalue reference into the language, <tt>Swappable</tt> needs to be updated to
-require only <tt>MoveConstructible</tt> and <tt>MoveAssignable</tt>. This is a minimum.
-</p>
-
-<p>
-Additionally we may want to support proxy references such that the following code is acceptable:
-</p>
-
-<blockquote><pre>namespace Mine {
-
-template &lt;class T&gt;
-struct proxy {...};
-
-template &lt;class T&gt;
-struct proxied_iterator
-{
- typedef T value_type;
- typedef proxy&lt;T&gt; reference;
- reference operator*() const;
- ...
-};
-
-struct A
-{
- // heavy type, has an optimized swap, maybe isn't even copyable or movable, just swappable
- void swap(A&amp;);
- ...
-};
-
-void swap(A&amp;, A&amp;);
-void swap(proxy&lt;A&gt;, A&amp;);
-void swap(A&amp;, proxy&lt;A&gt;);
-void swap(proxy&lt;A&gt;, proxy&lt;A&gt;);
-
-} // Mine
-
-...
-
-Mine::proxied_iterator&lt;Mine::A&gt; i(...)
-Mine::A a;
-swap(*i1, a);
-</pre></blockquote>
-
-<p>
-I.e. here is a call to <tt>swap</tt> which the user enables swapping between a proxy to a class and the class
-itself. We do not need to anything in terms of implementation except not block their way with overly
-constrained concepts. That is, the <tt>Swappable</tt> concept should be expanded to allow swapping
-between two different types for the case that one is binding to a user-defined <tt>swap</tt>.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 20.1.1 [utility.arg.requirements]:
-</p>
-
-<blockquote>
-
-<p>
--1- The template definitions in the C++ Standard Library refer to various
-named requirements whose details are set out in tables 31-38. In these
-tables, <tt>T</tt> is a type to be supplied by a C++ program
-instantiating a template; <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
-values of type <tt>const T</tt>; <tt>s</tt> and <tt>t</tt> are modifiable
-lvalues of type <tt>T</tt>; <tt>u</tt> is a value of type (possibly
-<tt>const</tt>) <tt>T</tt>; and <tt>rv</tt> is a non-<tt>const</tt>
-rvalue of type <tt>T</tt>.
-</p>
-
-<table border="1">
-<caption>Table 37: <tt>Swappable</tt> requirements <b>[swappable]</b></caption>
-<tbody><tr><th>expression</th><th>return type</th><th>post-condition</th></tr>
-<tr><td><tt>swap(s,t)</tt></td><td><tt>void</tt></td>
-<td><tt>t</tt> has the value originally
-held by <tt>u</tt>, and
-<tt>u</tt> has the value originally held
-by <tt>t</tt></td></tr>
-<tr><td colspan="3">
-<p>
-The <tt>Swappable</tt> requirement is met by satisfying one or more of the following conditions:
-</p>
-<ul>
-<li>
-<tt>T</tt> is <tt>Swappable</tt> if <tt>T</tt> satisfies the
-<del><tt>CopyConstructible</tt></del> <ins>MoveConstructible</ins>
-requirements (Table <del>34</del> <ins>33</ins>) and the <del><tt>CopyAssignable</tt></del> <ins>MoveAssignable</ins>
-requirements (Table <del>36</del> <ins>35</ins>);
-</li>
-<li>
-<tt>T</tt> is <tt>Swappable</tt> if a namespace scope function named
-<tt>swap</tt> exists in the same namespace as the definition of
-<tt>T</tt>, such that the expression
-<tt>swap(t,u)</tt> is valid and has the
-semantics described in this table.
-</li>
-</ul>
-</td></tr>
-</tbody></table>
-</blockquote>
-
-
-
-<p><i>[
-Kona (2007): We like the change to the <tt>Swappable</tt> requirements to use
-move semantics. The issue relating to the support of proxies is
-separable from the one relating to move semantics, and it's bigger than
-just swap. We'd like to address only the move semantics changes under
-this issue, and open a separated issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#742">742</a>) to handle proxies. Also, there
-may be a third issue, in that the current definition of <tt>Swappable</tt> does
-not permit rvalues to be operands to a swap operation, and Howard's
-proposed resolution would allow the right-most operand to be an rvalue,
-but it would not allow the left-most operand to be an rvalue (some swap
-functions in the library have been overloaded to permit left operands to
-swap to be rvalues).
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="673"></a>673. <tt>unique_ptr</tt> update</h3>
-<p><b>Section:</b> 20.7.11 [unique.ptr] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-05-04</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#unique.ptr">issues</a> in [unique.ptr].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Since the publication of
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
-there have been a few small but significant advances which should be included into
-<tt>unique_ptr</tt>. There exists a
-<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">example implmenation</a>
-for all of these changes.
-</p>
-
-<ul>
-
-<li>
-<p>
-Even though <tt>unique_ptr&lt;void&gt;</tt> is not a valid use case (unlike for <tt>shared_ptr&lt;void&gt;</tt>),
-unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr&lt;void&gt;</tt>
-even if it is never used. For example see
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
-happened to <tt>auto_ptr</tt>. I believe the most robust way to protect <tt>unique_ptr</tt> against this
-type of failure is to augment the return type of <tt>unique_ptr&lt;T&gt;:operator*()</tt> with
-<tt>add_lvalue_reference&lt;T&gt;::type</tt>. This means that given an instantiated <tt>unique_ptr&lt;void&gt;</tt>
-the act of dereferencing it will simply return <tt>void</tt> instead of causing a compile time failure.
-This is simpler than creating a <tt>unique_ptr&lt;void&gt;</tt> specialization which isn't robust in the
-face of <tt><i>cv-</i></tt>qualified <tt>void</tt> types.
-</p>
-
-<p>
-This resolution also supports instantiations such as <tt>unique_ptr&lt;void, free_deleter&gt;</tt>
-which could be very useful to the client.
-</p>
-
-</li>
-
-<li>
-<p>
-Efforts have been made to better support containers and smart pointers in shared
-memory contexts. One of the key hurdles in such support is not assuming that a
-pointer type is actually a <tt>T*</tt>. This can easily be accomplished
-for <tt>unique_ptr</tt> by having the deleter define the pointer type:
-<tt>D::pointer</tt>. Furthermore this type can easily be defaulted to
-<tt>T*</tt> should the deleter <tt>D</tt> choose not to define a pointer
-type (example implementation
-<a href="http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html">here</a>).
-This change has no run time overhead. It has no interface overhead on
-authors of custom delter types. It simply allows (but not requires)
-authors of custom deleter types to define a smart pointer for the
-storage type of <tt>unique_ptr</tt> if they find such functionality
-useful. <tt>std::default_delete</tt> is an example of a deleter which
-defaults <tt>pointer</tt> to <tt>T*</tt> by simply ignoring this issue
-and not including a <tt>pointer typedef</tt>.
-</p>
-</li>
-
-<li>
-<p>
-When the deleter type is a function pointer then it is unsafe to construct
-a <tt>unique_ptr</tt> without specifying the function pointer in the constructor.
-This case is easy to check for with a <tt>static_assert</tt> assuring that the
-deleter is not a pointer type in those constructors which do not accept deleters.
-</p>
-
-<blockquote><pre>unique_ptr&lt;A, void(*)(void*)&gt; p(new A); // error, no function given to delete the pointer!
-</pre></blockquote>
-
-</li>
-
-</ul>
-
-<p><i>[
-Kona (2007): We don't like the solution given to the first bullet in
-light of concepts. The second bullet solves the problem of supporting
-fancy pointers for one library component only. The full LWG needs to
-decide whether to solve the problem of supporting fancy pointers
-piecemeal, or whether a paper addressing the whole library is needed. We
-think that the third bullet is correct.
-]</i></p>
-
-
-<p><i>[
-Post Kona: Howard adds example user code related to the first bullet:
-]</i></p>
-
-
-<blockquote>
-<pre>void legacy_code(void*, std::size_t);
-
-void foo(std::size_t N)
-{
- std::unique_ptr&lt;void, void(*)(void*)&gt; ptr(std::malloc(N), std::free);
- legacy_code(ptr.get(), N);
-} // unique_ptr used for exception safety purposes
-</pre>
-</blockquote>
-
-<p>
-I.e. <tt>unique_ptr&lt;void&gt;</tt> <i>is</i> a useful tool that we don't want
-to disable with concepts. The only part of <tt>unique_ptr&lt;void&gt;</tt> we
-want to disable (with concepts or by other means) are the two member functions:
-</p>
-
-<blockquote><pre>T&amp; operator*() const;
-T* operator-&gt;() const;
-</pre></blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p><i>[
-I am grateful for the generous aid of Peter Dimov and Ion Gaztaaga in helping formulate and review
-the proposed resolutions below.
-]</i></p>
-
-
-<ul>
-<li>
-
-<p>
-Change 20.7.11.2 [unique.ptr.single]:
-</p>
-
-<blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
- ...
- <del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
- ...
-};
-</pre></blockquote>
-
-<p>
-Change 20.7.11.2.4 [unique.ptr.single.observers]:
-</p>
-
-<blockquote><pre><del>T&amp;</del> <ins>typename add_lvalue_reference&lt;T&gt;::type</ins> operator*() const;
-</pre></blockquote>
-
-</li>
-
-<li>
-<p>
-Change 20.7.11.2 [unique.ptr.single]:
-</p>
-
-<blockquote><pre>template &lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr {
-public:
- <ins>typedef <i>implementation (see description below)</i> pointer;</ins>
- ...
- explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
- ...
- unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
- unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined (see description below)</i> d);
- ...
- <del>T*</del> <ins>pointer</ins> operator-&gt;() const;
- <del>T*</del> <ins>pointer</ins> get() const;
- ...
- <del>T*</del> <ins>pointer</ins> release();
- void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-};
-</pre></blockquote>
-
-<p>
-<ins>
--3- If the type <tt>remove_reference&lt;D&gt;::type::pointer</tt>
-exists, then <tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to
-<tt>remove_reference&lt;D&gt;::type::pointer</tt>. Otherwise
-<tt>unique_ptr&lt;T, D&gt;::pointer</tt> is a typedef to <tt>T*</tt>.
-The type <tt>unique_ptr&lt;T, D&gt;::pointer</tt> shall be <tt>CopyConstructible</tt>
-and <tt>CopyAssignable</tt>.
-</ins>
-</p>
-
-<p>
-Change 20.7.11.2.1 [unique.ptr.single.ctor]:
-</p>
-
-<blockquote><pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
-...
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
-...
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
-...
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp; d);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, A&amp;&amp; d);
-...
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp; d);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, const A&amp;&amp; d);
-...
-</pre></blockquote>
-
-<p>
--23- <i>Requires:</i> If <tt>D</tt> is not a reference type,
-construction of the deleter <tt>D</tt> from an rvalue of type <tt>E</tt>
-<del>must</del> <ins>shall</ins> be well formed and not throw an exception. If <tt>D</tt> is a
-reference type, then <tt>E</tt> <del>must</del> <ins>shall</ins> be the same type as <tt>D</tt>
-(diagnostic required). <del><tt>U*</tt></del> <ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins>
-<del>must</del> <ins>shall</ins> be implicitly convertible to <del><tt>T*</tt></del>
-<ins>pointer</ins>.
-</p>
-
-<p>
--25- <i>Postconditions:</i> <tt>get() == value u.get()</tt> had before
-the construction, modulo any required offset adjustments resulting from
-the cast from <del><tt>U*</tt></del>
-<ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> to <del><tt>T*</tt></del>
-<ins>pointer</ins>. <tt>get_deleter()</tt> returns a reference to the
-internally stored deleter which was constructed from
-<tt>u.get_deleter()</tt>.
-</p>
-
-<p>
-Change 20.7.11.2.3 [unique.ptr.single.asgn]:
-</p>
-
-<blockquote>
-<p>
--8- <i>Requires:</i> Assignment of the deleter <tt>D</tt> from an rvalue
-<tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception. <del><tt>U*</tt></del>
-<ins><tt>unique_ptr&lt;U,E&gt;::pointer</tt></ins> <del>must</del> <ins>shall</ins> be implicitly
-convertible to <del><tt>T*</tt></del> <ins>pointer</ins>.
-</p>
-</blockquote>
-
-<p>
-Change 20.7.11.2.4 [unique.ptr.single.observers]:
-</p>
-
-<blockquote>
-<pre><del>T*</del> <ins>pointer</ins> operator-&gt;() const;</pre>
-...
-<pre><del>T*</del> <ins>pointer</ins> get() const;</pre>
-</blockquote>
-
-<p>
-Change 20.7.11.2.5 [unique.ptr.single.modifiers]:
-</p>
-
-<blockquote>
-<pre><del>T*</del> <ins>pointer</ins> release();</pre>
-...
-<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);</pre>
-</blockquote>
-
-<p>
-Change 20.7.11.3 [unique.ptr.runtime]:
-</p>
-
-<blockquote><pre>template &lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt; {
-public:
- <ins>typedef <i>implementation</i> pointer;</ins>
- ...
- explicit unique_ptr(<del>T*</del> <ins>pointer</ins> p);
- ...
- unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
- unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
- ...
- <del>T*</del> <ins>pointer</ins> get() const;
- ...
- <del>T*</del> <ins>pointer</ins> release();
- void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-};
-</pre></blockquote>
-
-<p>
-Change 20.7.11.3.1 [unique.ptr.runtime.ctor]:
-</p>
-
-<blockquote>
-<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
-unique_ptr(<del>T*</del> <ins>pointer</ins> p, <i>implementation defined</i> d);
-</pre>
-
-<p>
-These constructors behave the same as in the primary template except
-that they do not accept pointer types which are convertible to
-<del><tt>T*</tt></del> <ins><tt>pointer</tt></ins>. [<i>Note:</i> One
-implementation technique is to create private templated overloads of
-these members. <i>-- end note</i>]
-</p>
-</blockquote>
-
-<p>
-Change 20.7.11.3.3 [unique.ptr.runtime.modifiers]:
-</p>
-
-<blockquote>
-<pre>void reset(<del>T*</del> <ins>pointer</ins> p = <del>0</del> <ins>pointer()</ins>);
-</pre>
-
-<p>
--1- <i>Requires:</i> Does not accept pointer types which are convertible
-to <del><tt>T*</tt></del> <ins><tt>pointer</tt></ins> (diagnostic
-required). [<i>Note:</i> One implementation technique is to create a private
-templated overload. <i>-- end note</i>]
-</p>
-</blockquote>
-
-</li>
-
-<li>
-
-<p>
-Change 20.7.11.2.1 [unique.ptr.single.ctor]:
-</p>
-
-<blockquote>
-<pre>unique_ptr();</pre>
-<blockquote>
-<p>
-<i>Requires:</i> <tt>D</tt> <del>must</del> <ins>shall</ins> be default constructible, and that
-construction <del>must</del> <ins>shall</ins> not throw an exception. <tt>D</tt> <del>must</del> <ins>shall</ins> not be a
-reference type <ins>or pointer type (diagnostic required)</ins>.
-</p>
-</blockquote>
-<pre>unique_ptr(<del>T*</del> <ins>pointer</ins> p);</pre>
-<blockquote>
-<p>
-<i>Requires:</i> The expression <tt>D()(p)</tt> <del>must</del> <ins>shall</ins> be well formed.
-The default constructor of <tt>D</tt> <del>must</del> <ins>shall</ins> not throw an exception.
-<tt>D</tt> <del>must</del> <ins>shall</ins> not be a reference type <ins>or pointer type (diagnostic
-required)</ins>.
-</p>
-</blockquote>
-</blockquote>
-
-</li>
-
-</ul>
-
-
-
-
-
-
-<hr>
-<h3><a name="674"></a>674. <tt>shared_ptr</tt> interface changes for consistency with N1856</h3>
-<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-05</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a> does not propose
-any changes to <tt>shared_ptr</tt>. It needs to be updated to use a rvalue reference where appropriate
-and to interoperate with <tt>unique_ptr</tt> as it does with <tt>auto_ptr</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change 20.7.12.2 [util.smartptr.shared] as follows:
-</p>
-
-<blockquote>
-<pre>template&lt;class Y&gt; explicit shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
-<ins>template&lt;class Y, class D&gt; explicit shared_ptr(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
-template&lt;class Y, class D&gt; explicit shared_ptr(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins>
-...
-template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);
-<ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(const unique_ptr&lt;Y,D&gt;&amp; r) = delete;
-template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
-</blockquote>
-
-<p>
-Change 20.7.12.2.1 [util.smartptr.shared.const] as follows:
-</p>
-
-<blockquote>
-<pre><ins>template&lt;class Y&gt; shared_ptr(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</ins></pre>
-</blockquote>
-
-<p>
-Add to 20.7.12.2.1 [util.smartptr.shared.const]:
-</p>
-
-<blockquote>
-<pre><ins>template&lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);</ins></pre>
-<blockquote>
-
-<p><ins>
-<i>Effects:</i> Equivalent to <tt>shared_ptr( r.release(), r.get_deleter() )</tt> when <tt>D</tt> is
- not a reference type, <tt>shared_ptr( r.release(), ref( r.get_deleter() ) )</tt>
- otherwise.
-</ins></p>
-
-<p><ins>
-<i>Exception safety:</i> If an exception is thrown, the constructor has no effect.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-<p>
-Change 20.7.12.2.3 [util.smartptr.shared.assign] as follows:
-</p>
-
-<blockquote>
-<pre>template&lt;class Y&gt; shared_ptr&amp; operator=(auto_ptr&lt;Y&gt;<del>&amp;</del><ins>&amp;&amp;</ins> r);</pre>
-</blockquote>
-
-<p>
-Add to 20.7.12.2.3 [util.smartptr.shared.assign]:
-</p>
-
-<blockquote>
-<pre><ins>template&lt;class Y, class D&gt; shared_ptr&amp; operator=(unique_ptr&lt;Y,D&gt;&amp;&amp; r);</ins></pre>
-
-<blockquote>
-<p><ins>
--4- <i>Effects:</i> Equivalent to <tt>shared_ptr(std::move(r)).swap(*this)</tt>.
-</ins></p>
-<p><ins>
--5- <i>Returns:</i> <tt>*this</tt>.
-</ins></p>
-</blockquote>
-
-</blockquote>
-
-
-
-<p><i>[
-Kona (2007): We may need to open an issue (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#743">743</a>) to deal with the question of
-whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="677"></a>677. Weaknesses in seed_seq::randomize [rand.util.seedseq]</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>seed_seq::randomize</tt> provides a mechanism for initializing random number
-engines which ideally would yield "distant" states when given "close"
-seeds. The algorithm for <tt>seed_seq::randomize</tt> given in the current
-Working Draft for C++,
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
-(2007-05-08), has 3 weaknesses
-</p>
-
-<ol>
-<li>
-<p> Collisions in state. Because of the way the state is initialized,
- seeds of different lengths may result in the same state. The
- current version of seed_seq has the following properties:</p>
-<ul>
-<li> For a given <tt>s &lt;= n</tt>, each of the 2^(32s) seed vectors results in a
- distinct state.</li>
-</ul>
-<p>
- The proposed algorithm (below) has the considerably stronger
- properties:</p>
-<ul>
-<li> All of the <tt>(2^(32n)-1)/(2^32-1)</tt> seed vectors of lengths <tt>s &lt; n</tt>
- result in distinct states.
-</li>
-<li> All of the <tt>2^(32n)</tt> seed vectors of length <tt>s == n</tt> result in
- distinct states.
-</li>
-</ul>
-</li>
-<li>
-<p> Poor mixing of <tt>v'</tt>s entropy into the state. Consider <tt>v.size() == n</tt>
- and hold <tt>v[n/2]</tt> thru <tt>v[n-1]</tt> fixed while varying <tt>v[0]</tt> thru <tt>v[n/2-1]</tt>,
- a total of <tt>2^(16n)</tt> possibilities. Because of the simple recursion
- used in <tt>seed_seq</tt>, <tt>begin[n/2]</tt> thru <tt>begin[n-1]</tt> can take on only 2^64
- possible states.</p>
-
-<p> The proposed algorithm uses a more complex recursion which results
- in much better mixing.</p>
-</li>
-<li> <tt>seed_seq::randomize</tt> is undefined for <tt>v.size() == 0</tt>. The proposed
- algorithm remedies this.
-</li>
-</ol>
-<p>
-The current algorithm for <tt>seed_seq::randomize</tt> is adapted by me from the
-initialization procedure for the Mersenne Twister by Makoto Matsumoto
-and Takuji Nishimura. The weakness (2) given above was communicated to
-me by Matsumoto last year.
-</p>
-<p>
-The proposed replacement for <tt>seed_seq::randomize</tt> is due to Mutsuo Saito,
-a student of Matsumoto, and is given in the implementation of the
-SIMD-oriented Fast Mersenne Twister random number generator SFMT.
-<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/index.html">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html</a>
-<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/SFMT-src-1.2.tar.gz">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/SFMT-src-1.2.tar.gz</a>
-</p>
-<p>
-See
-Mutsuo Saito,
-An Application of Finite Field: Design and Implementation of 128-bit
-Instruction-Based Fast Pseudorandom Number Generator,
-Master's Thesis, Dept. of Math., Hiroshima University (Feb. 2007)
-<a href="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/SFMT/M062821.pdf">http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/M062821.pdf</a>
-</p>
-<p>
-One change has been made here, namely to treat the case of small <tt>n</tt>
-(setting <tt>t = (n-1)/2</tt> for <tt>n &lt; 7</tt>).
-</p>
-<p>
-Since <tt>seed_seq</tt> was introduced relatively recently there is little cost
-in making this incompatible improvement to it.
-</p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
-</p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="678"></a>678. Changes for [rand.req.eng]</h3>
-<p><b>Section:</b> 26.4.1.3 [rand.req.eng] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Charles Karney <b>Date:</b> 2007-05-15</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.req.eng">issues</a> in [rand.req.eng].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Section 26.4.1.3 [rand.req.eng] Random number engine requirements:
-</p>
-
-<p>
-This change follows naturally from the proposed change to
-<tt>seed_seq::randomize</tt> in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#677">677</a>.
-</p>
-
-<p>
-In table 104 the description of <tt>X(q)</tt> contains a special treatment of
-the case <tt>q.size() == 0</tt>. This is undesirable for 4 reasons:
-</p>
-
-<ol>
-<li>It replicates the functionality provided by <tt>X()</tt>.</li>
-<li>It leads to the possibility of a collision in the state provided
- by some other <tt>X(q)</tt> with <tt>q.size() &gt; 0</tt>.</li>
-<li>It is inconsistent with the description of the <tt>X(q)</tt> in
-paragraphs 26.4.3.1 [rand.eng.lcong] p5, 26.4.3.2 [rand.eng.mers] p8, and 26.4.3.3 [rand.eng.sub] p10 where
-there is no special treatment of <tt>q.size() == 0</tt>.</li>
-<li>The proposed replacement for <tt>seed_seq::randomize</tt> given above
- allows for the case <tt>q.size() == 0</tt>.</li>
-</ol>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
-</p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="679"></a>679. resize parameter by value</h3>
-<p><b>Section:</b> 23.2 [sequences] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The C++98 standard specifies that one member function alone of the containers
-passes its parameter (<tt>T</tt>) by value instead of by const reference:
-</p>
-
-<blockquote><pre>void resize(size_type sz, T c = T());
-</pre></blockquote>
-
-<p>
-This fact has been discussed / debated repeatedly over the years, the first time
-being even before C++98 was ratified. The rationale for passing this parameter by
-value has been:
-</p>
-
-<blockquote>
-<p>
-So that self referencing statements are guaranteed to work, for example:
-</p>
-<blockquote><pre>v.resize(v.size() + 1, v[0]);
-</pre></blockquote>
-</blockquote>
-
-<p>
-However this rationale is not convincing as the signature for <tt>push_back</tt> is:
-</p>
-
-<blockquote><pre>void push_back(const T&amp; x);
-</pre></blockquote>
-
-<p>
-And <tt>push_back</tt> has similar semantics to <tt>resize</tt> (append).
-And <tt>push_back</tt> must also work in the self referencing case:
-</p>
-
-<blockquote><pre>v.push_back(v[0]); // must work
-</pre></blockquote>
-
-<p>
-The problem with passing <tt>T</tt> by value is that it can be significantly more
-expensive than passing by reference. The converse is also true, however when it is
-true it is usually far less dramatic (e.g. for scalar types).
-</p>
-
-<p>
-Even with move semantics available, passing this parameter by value can be expensive.
-Consider for example <tt>vector&lt;vector&lt;int&gt;&gt;</tt>:
-</p>
-
-<blockquote><pre>std::vector&lt;int&gt; x(1000);
-std::vector&lt;std::vector&lt;int&gt;&gt; v;
-...
-v.resize(v.size()+1, x);
-</pre></blockquote>
-
-<p>
-In the pass-by-value case, <tt>x</tt> is copied once to the parameter of
-<tt>resize</tt>. And then internally, since the code can not know at compile
-time by how much <tt>resize</tt> is growing the <tt>vector</tt>, <tt>x</tt> is
-usually copied (not moved) a second time from <tt>resize</tt>'s parameter into its proper place
-within the <tt>vector</tt>.
-</p>
-
-<p>
-With pass-by-const-reference, the <tt>x</tt> in the above example need be copied
-only once. In this case, <tt>x</tt> has an expensive copy constructor and so any
-copies that can be saved represents a significant savings.
-</p>
-
-<p>
-If we can be efficient for <tt>push_back</tt>, we should be efficient for <tt>resize</tt>
-as well. The resize taking a reference parameter has been coded and shipped in the
-CodeWarrior library with no reports of problems which I am aware of.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 23.2.2 [deque], p2:
-</p>
-
-<blockquote><pre>class deque {
- ...
- void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
-
-<p>
-Change 23.2.2.2 [deque.capacity], p3:
-</p>
-
-<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
-
-<p>
-Change 23.2.4 [list], p2:
-</p>
-
-<blockquote><pre>class list {
- ...
- void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
-
-<p>
-Change 23.2.4.2 [list.capacity], p3:
-</p>
-
-<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
-
-<p>
-Change 23.2.6 [vector], p2:
-</p>
-
-<blockquote><pre>class vector {
- ...
- void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
-
-<p>
-Change 23.2.6.2 [vector.capacity], p11:
-</p>
-
-<blockquote><pre>void resize(size_type sz, <ins>const </ins>T<ins>&amp;</ins> c);
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="680"></a>680. move_iterator operator-&gt; return</h3>
-<p><b>Section:</b> 24.4.3.1 [move.iterator] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-06-11</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>move_iterator</tt>'s <tt>operator-&gt;</tt> return type <tt>pointer</tt>
-does not consistently match the type which is returned in the description
-in 24.4.3.3.5 [move.iter.op.ref].
-</p>
-
-<blockquote><pre>template &lt;class Iterator&gt;
-class move_iterator {
-public:
- ...
- typedef typename iterator_traits&lt;Iterator&gt;::pointer pointer;
- ...
- pointer operator-&gt;() const {return current;}
- ...
-private:
- Iterator current; // exposition only
-};
-</pre></blockquote>
-
-
-<p>
-There are two possible fixes.
-</p>
-
-<ol>
-<li><tt>pointer operator-&gt;() const {return &amp;*current;}</tt></li>
-<li><tt>typedef Iterator pointer;</tt></li>
-</ol>
-
-<p>
-The first solution is the one chosen by <tt>reverse_iterator</tt>. A potential
-disadvantage of this is it may not work well with iterators which return a
-proxy on dereference and that proxy has overloaded <tt>operator&amp;()</tt>. Proxy
-references often need to overloaad <tt>operator&amp;()</tt> to return a proxy
-pointer. That proxy pointer may or may not be the same type as the iterator's
-<tt>pointer</tt> type.
-</p>
-
-<p>
-By simply returning the <tt>Iterator</tt> and taking advantage of the fact that
-the language forwards calls to <tt>operator-&gt;</tt> automatically until it
-finds a non-class type, the second solution avoids the issue of an overloaded
-<tt>operator&amp;()</tt> entirely.
-</p>
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 24.4.3.1 [move.iterator]:
-</p>
-
-<blockquote><pre>typedef <del>typename iterator_traits&lt;</del>Iterator<del>&gt;::pointer</del> pointer;
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="681"></a>681. Operator functions impossible to compare are defined in [re.submatch.op]</h3>
-<p><b>Section:</b> 28.9.2 [re.submatch.op] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Nozomu Katoo <b>Date:</b> 2007-05-27</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In 28.9.2 [re.submatch.op] of N2284,
-operator functions numbered 31-42 seem impossible to compare. &nbsp;E.g.:
-</p>
-
-<blockquote>
-<pre>template &lt;class BiIter&gt;
-&nbsp; &nbsp; bool operator==(typename iterator_traits&lt;BiIter&gt;::value_type const&amp; lhs,
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; const sub_match&lt;BiIter&gt;&amp; rhs);
-</pre>
-<blockquote>
-<p>
--31- <i>Returns:</i> <tt>lhs == rhs.str()</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-When <tt>char*</tt> is used as <tt>BiIter</tt>, <tt>iterator_traits&lt;BiIter&gt;::value_type</tt> would be
-<tt>char</tt>, so that <tt>lhs == rhs.str()</tt> ends up comparing a <tt>char</tt> value and an object
-of <tt>std::basic_string&lt;char&gt;</tt>. &nbsp;However, the behaviour of comparison between
-these two types is not defined in 21.3.8 [string.nonmembers] of N2284.
-&nbsp;This applies when <tt>wchar_t*</tt> is used as <tt>BiIter</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
-</p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="682"></a>682. basic_regex ctor takes InputIterator or ForwardIterator?</h3>
-<p><b>Section:</b> 28.8.2 [re.regex.construct] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Eric Niebler <b>Date:</b> 2007-06-03</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Looking at N2284, 28.8 [re.regex], p3 <tt>basic_regex</tt> class template synopsis shows this
-constructor:
-</p>
-<blockquote><pre>template &lt;class InputIterator&gt;
-&nbsp; &nbsp; &nbsp;basic_regex(InputIterator first, InputIterator last,
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
-
-<p>
-In 28.8.2 [re.regex.construct], p15, the constructor appears with this signature:
-</p>
-
-<blockquote><pre>template &lt;class ForwardIterator&gt;
-&nbsp; &nbsp; &nbsp;basic_regex(ForwardIterator first, ForwardIterator last,
-&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;flag_type f = regex_constants::ECMAScript);
-</pre></blockquote>
-
-<p>
-<tt>ForwardIterator</tt> is probably correct, so the synopsis is wrong.
-</p>
-
-<p><i>[
-John adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-I think either could be implemented? &nbsp;Although an input iterator would
-probably require an internal copy of the string being made.
-</p>
-<p>
-I have no strong feelings either way, although I think my original intent
-was <tt>InputIterator</tt>.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2409.pdf">N2409</a>.
-</p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2409 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="685"></a>685. reverse_iterator/move_iterator difference has invalid signatures</h3>
-<p><b>Section:</b> 24.4.1.3.19 [reverse.iter.opdiff], 24.4.3.3.14 [move.iter.nonmember] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Bo Persson <b>Date:</b> 2007-06-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In C++03 the difference between two <tt>reverse_iterators</tt>
-</p>
-<blockquote><pre>ri1 - ri2
-</pre></blockquote>
-<p>
-is possible to compute only if both iterators have the same base
-iterator. The result type is the <tt>difference_type</tt> of the base iterator.
-</p>
-<p>
-In the current draft, the operator is defined as 24.4.1.3.19 [reverse.iter.opdiff]
-</p>
-<blockquote><pre>template&lt;class Iterator1, class Iterator2&gt;
-typename reverse_iterator&lt;Iterator&gt;::difference_type
- operator-(const reverse_iterator&lt;Iterator1&gt;&amp; x,
- const reverse_iterator&lt;Iterator2&gt;&amp; y);
-</pre></blockquote>
-<p>
-The return type is the same as the C++03 one, based on the no longer
-present <tt>Iterator</tt> template parameter.
-</p>
-<p>
-Besides being slightly invalid, should this operator work only when
-<tt>Iterator1</tt> and <tt>Iterator2</tt> has the same <tt>difference_type</tt>? Or should the
-implementation choose one of them? Which one?
-</p>
-<p>
-The same problem now also appears in <tt>operator-()</tt> for <tt>move_iterator</tt>
-24.4.3.3.14 [move.iter.nonmember].
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 24.4.1.1 [reverse.iterator]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Iterator1, class Iterator2&gt;
- <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
- const reverse_iterator&lt;Iterator1&gt;&amp; x,
- const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
-</pre>
-</blockquote>
-
-<p>
-Change 24.4.1.3.19 [reverse.iter.opdiff]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Iterator1, class Iterator2&gt;
- <del>typename reverse_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
- const reverse_iterator&lt;Iterator1&gt;&amp; x,
- const reverse_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(y.current - x.current)</ins>;
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>y.current - x.current</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-<p>
-Change the synopsis in 24.4.3.1 [move.iterator]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Iterator1, class Iterator2&gt;
- <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
- const move_iterator&lt;Iterator1&gt;&amp; x,
- const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
-</pre>
-</blockquote>
-
-<p>
-Change 24.4.3.3.14 [move.iter.nonmember]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Iterator1, class Iterator2&gt;
- <del>typename move_iterator&lt;Iterator&gt;::difference_type</del> <ins>auto</ins> operator-(
- const move_iterator&lt;Iterator1&gt;&amp; x,
- const move_iterator&lt;Iterator2&gt;&amp; y)<ins> -&gt; decltype(x.base() - y.base())</ins>;
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>x.base() - y.base()</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<p><i>[
-Pre Bellevue: This issue needs to wait until the <tt>auto -&gt; return</tt> language feature
-goes in.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="687"></a>687. shared_ptr conversion constructor not constrained</h3>
-<p><b>Section:</b> 20.7.12.2.1 [util.smartptr.shared.const], 20.7.12.3.1 [util.smartptr.weak.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Since all conversions from <tt>shared_ptr&lt;T&gt;</tt> to <tt>shared_ptr&lt;U&gt;</tt> have the same
-rank regardless of the relationship between <tt>T</tt> and <tt>U</tt>, reasonable user
-code that works with raw pointers fails with <tt>shared_ptr</tt>:
-</p>
-
-<blockquote><pre>void f( shared_ptr&lt;void&gt; );
-void f( shared_ptr&lt;int&gt; );
-
-int main()
-{
-&nbsp;&nbsp;f( shared_ptr&lt;double&gt;() ); // ambiguous
-}
-</pre></blockquote>
-
-<p>
-Now that we officially have <tt>enable_if</tt>, we can constrain the constructor
-and the corresponding assignment operator to only participate in the
-overload resolution when the pointer types are compatible.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.7.12.2.1 [util.smartptr.shared.const], change:
-</p>
-
-<blockquote><p>
--14- <i>Requires:</i> <del>For the second constructor</del> <ins>The
-second constructor shall not participate in the overload resolution
-unless</ins> <tt>Y*</tt> <del>shall be</del> <ins>is implicitly</ins> convertible
-to <tt>T*</tt>.
-</p></blockquote>
-
-<p>
-In 20.7.12.3.1 [util.smartptr.weak.const], change:
-</p>
-
-<blockquote>
-<pre><del>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</del>
-<del>weak_ptr(weak_ptr const&amp; r);</del>
-<del>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</del>
-<ins>weak_ptr(weak_ptr const&amp; r);</ins>
-<ins>template&lt;class Y&gt; weak_ptr(weak_ptr&lt;Y&gt; const&amp; r);</ins>
-<ins>template&lt;class Y&gt; weak_ptr(shared_ptr&lt;Y&gt; const&amp; r);</ins>
-</pre>
-<blockquote><p>
--4- <i>Requires:</i> <del>For</del> <del>t</del><ins>T</ins>he second and
-third constructors<del>,</del> <ins>shall not participate in the
-overload resolution unless</ins> <tt>Y*</tt> <del>shall be</del>
-<ins>is implicitly</ins> convertible to <tt>T*</tt>.
-</p></blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="689"></a>689. reference_wrapper constructor overly constrained</h3>
-<p><b>Section:</b> 20.6.5.1 [refwrap.const] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-05-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#refwrap.const">issues</a> in [refwrap.const].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The constructor of <tt>reference_wrapper</tt> is currently <tt>explicit</tt>. The primary
-motivation behind this is the safety problem with respect to rvalues,
-which is addressed by the proposed resolution of the previous issue.
-Therefore we should consider relaxing the requirements on the
-constructor since requests for the implicit conversion keep resurfacing.
-</p>
-<p>
-Also please see the thread starting at c++std-lib-17398 for some good discussion on this subject.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove the <tt>explicit</tt> from the constructor of <tt>reference_wrapper</tt>. If the
-proposed resolution of the previous issue is accepted, remove the
-<tt>explicit</tt> from the <tt>T&amp;&amp;</tt> constructor as well to keep them in sync.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="693"></a>693. <code>std::bitset::all()</code> missing</h3>
-<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The <code>bitset</code> class template provides the member function
-<code>any()</code> to determine whether an object of the type has any
-bits set, and the member function <code>none()</code> to determine
-whether all of an object's bits are clear. However, the template does
-not provide a corresponding function to discover whether a
-<code>bitset</code> object has all its bits set. While it is
-possible, even easy, to obtain this information by comparing the
-result of <code>count()</code> with the result of <code>size()</code>
-for equality (i.e., via <code>b.count() == b.size()</code>) the
-operation is less efficient than a member function designed
-specifically for that purpose could be. (<code>count()</code> must
-count all non-zero bits in a <code>bitset</code> a word at a time
-while <code>all()</code> could stop counting as soon as it encountered
-the first word with a zero bit).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a declaration of the new member function <code>all()</code> to the
-defintion of the <code>bitset</code> template in 23.3.5 [template.bitset], p1,
-right above the declaration of <code>any()</code> as shown below:
-</p>
-
-<blockquote><pre>bool operator!=(const bitset&lt;N&gt;&amp; rhs) const;
-bool test(size_t pos) const;
-<ins>bool all() const;</ins>
-bool any() const;
-bool none() const;
-</pre></blockquote>
-
-<p>
-Add a description of the new member function to the end of 23.3.5.2 [bitset.members] with the following text:
-</p>
-<blockquote><p>
-<code>bool all() const;</code>
-</p>
-<blockquote>
-<i>Returns</i>: <code>count() == size()</code>.
-</blockquote>
-</blockquote>
-
-<p>
-In addition, change the description of <code>any()</code> and
-<code>none()</code> for consistency with <code>all()</code> as
-follows:
-</p>
-<blockquote><p>
-<code>bool any() const;</code>
-</p>
-<blockquote>
-<p>
-<i>Returns</i>: <del><code>true</code> if any bit in <code>*this</code>
-is one</del><ins><code>count() != 0</code></ins>.
-</p>
-</blockquote>
-<p>
-<code>bool none() const;</code>
-</p>
-<blockquote>
-<p>
-<i>Returns</i>: <del><code>true</code> if no bit in <code>*this</code>
-is one</del><ins><code>count() == 0</code></ins>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="694"></a>694. <code>std::bitset</code> and <code>long long</code></h3>
-<p><b>Section:</b> 23.3.5 [template.bitset] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#template.bitset">issues</a> in [template.bitset].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Objects of the <code>bitset</code> class template specializations can
-be constructed from and explicitly converted to values of the widest
-C++ integer type, <code>unsigned long</code>. With the introduction
-of <code>long long</code> into the language the template should be
-enhanced to make it possible to interoperate with values of this type
-as well, or perhaps <code>uintmax_t</code>. See c++std-lib-18274 for
-a brief discussion in support of this change.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-For simplicity, instead of adding overloads for <code>unsigned long
-long</code> and dealing with possible ambiguities in the spec, replace
-the <code>bitset</code> ctor that takes an <code>unsigned long</code>
-argument with one taking <code>unsigned long long</code> in the
-definition of the template as shown below. (The standard permits
-implementations to add overloads on other integer types or employ
-template tricks to achieve the same effect provided they don't cause
-ambiguities or changes in behavior.)
-</p>
-<blockquote>
-<pre>// [bitset.cons] constructors:
-bitset();
-bitset(unsigned <ins>long</ins> long val);
-template&lt;class charT, class traits, class Allocator&gt;
-explicit bitset(
- const basic_string&lt;charT,traits,Allocator&gt;&amp; str,
- typename basic_string&lt;charT,traits,Allocator&gt;::size_type pos = 0,
- typename basic_string&lt;charT,traits,Allocator&gt;::size_type n =
- basic_string&lt;charT,traits,Allocator&gt;::npos);
-</pre>
-</blockquote>
-<p>
-Make a corresponding change in 23.3.5.1 [bitset.cons], p2:
-</p>
-<blockquote>
-<p>
-<code>bitset(unsigned <ins>long</ins> long val);</code>
-</p>
-<blockquote>
-<i>Effects</i>: Constructs an object of class bitset&lt;N&gt;,
-initializing the first <code><i>M</i></code> bit positions to the
-corresponding bit values in <code><i>val</i></code>.
-<code><i>M</i></code> is the smaller of <code><i>N</i></code> and the
-number of bits in the value representation (section [basic.types]) of
-<code>unsigned <ins> long</ins> long</code>. If <code><i>M</i> &lt;
-<i>N</i></code> <ins>is <code>true</code></ins>, the remaining bit
-positions are initialized to zero.
-</blockquote>
-</blockquote>
-
-<p>
-Additionally, introduce a new member function <code>to_ullong()</code>
-to make it possible to convert <code>bitset</code> to values of the
-new type. Add the following declaration to the definition of the
-template, immediate after the declaration of <code>to_ulong()</code>
-in 23.3.5 [template.bitset], p1, as shown below:
-</p>
-<blockquote>
-<pre>// element access:
-bool operator[](size_t pos) const; // for b[i];
-reference operator[](size_t pos); // for b[i];
-unsigned long to_ulong() const;
-<ins>unsigned long long to_ullong() const;</ins>
-template &lt;class charT, class traits, class Allocator&gt;
-basic_string&lt;charT, traits, Allocator&gt; to_string() const;
-</pre>
-</blockquote>
-<p>
-And add a description of the new member function to 23.3.5.2 [bitset.members],
-below the description of the existing <code>to_ulong()</code> (if
-possible), with the following text:
-</p>
-<blockquote>
-<p>
-<code>unsigned long long to_ullong() const;</code>
-</p>
-<blockquote>
-<i>Throws</i>: <code>overflow_error</code> if the integral value
-<code><i>x</i></code> corresponding to the bits in <code>*this</code>
-cannot be represented as type <code>unsigned long long</code>.
-</blockquote>
-<blockquote>
-<i>Returns:</i> <code><i>x</i></code>.
-</blockquote>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="695"></a>695. ctype&lt;char&gt;::classic_table() not accessible</h3>
-<p><b>Section:</b> 22.2.1.3 [facet.ctype.special] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Martin Sebor <b>Date:</b> 2007-06-22</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The <code>ctype&lt;char&gt;::classic_table()</code> static member
-function returns a pointer to an array of const
-<code>ctype_base::mask</code> objects (enums) that contains
-<code>ctype&lt;char&gt;::table_size</code> elements. The table
-describes the properties of the character set in the "C" locale (i.e.,
-whether a character at an index given by its value is alpha, digit,
-punct, etc.), and is typically used to initialize the
-<code>ctype&lt;char&gt;</code> facet in the classic "C" locale (the
-protected <code>ctype&lt;char&gt;</code> member function
-<code>table()</code> then returns the same value as
-<code>classic_table()</code>).
-</p>
-<p>
-However, while <code>ctype&lt;char&gt;::table_size</code> (the size of
-the table) is a public static const member of the
-<code>ctype&lt;char&gt;</code> specialization, the
-<code>classic_table()</code> static member function is protected. That
-makes getting at the classic data less than convenient (i.e., one has
-to create a whole derived class just to get at the masks array). It
-makes little sense to expose the size of the table in the public
-interface while making the table itself protected, especially when the
-table is a constant object.
-</p>
-<p>
-The same argument can be made for the non-static protected member
-function <code>table()</code>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Make the <code>ctype&lt;char&gt;::classic_table()</code> and
-<code>ctype&lt;char&gt;::table()</code> member functions public by
-moving their declarations into the public section of the definition of
-specialization in 22.2.1.3 [facet.ctype.special] as shown below:
-</p>
-<blockquote>
-<pre> static locale::id id;
- static const size_t table_size = IMPLEMENTATION_DEFINED;
-<del>protected:</del>
- const mask* table() const throw();
- static const mask* classic_table() throw();
-<ins>protected:</ins>
-
-~ctype(); // virtual
-virtual char do_toupper(char c) const;
-</pre>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="699"></a>699. N2111 changes min/max</h3>
-<p><b>Section:</b> 26.4 [rand] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand">issues</a> in [rand].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2111.pdf">N2111</a>
-changes <tt>min/max</tt> in several places in random from member
-functions to static data members. I believe this introduces
-a needless backward compatibility problem between C++0X and
-TR1. I'd like us to find new names for the static data members,
-or perhaps change <tt>min/max</tt> to <tt>constexpr</tt>s in C++0X.
-</p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
-</p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="700"></a>700. N1856 defines struct <tt>identity</tt></h3>
-<p><b>Section:</b> 20.2.2 [forward] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2007-07-01</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#forward">active issues</a> in [forward].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#forward">issues</a> in [forward].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html">N1856</a>
-defines struct <tt>identity</tt> in <tt>&lt;utility&gt;</tt> which clashes with
-the traditional definition of struct <tt>identity</tt> in <tt>&lt;functional&gt;</tt>
-(not standard, but a common extension from old STL). Be nice
-if we could avoid this name clash for backward compatibility.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.2.2 [forward]:
-</p>
-
-<blockquote>
-<pre>template &lt;class T&gt; struct identity
-{
- typedef T type;
- <ins>const T&amp; operator()(const T&amp; x) const;</ins>
-};
-</pre>
-<blockquote>
-<pre><ins>const T&amp; operator()(const T&amp; x) const;</ins>
-</pre>
-<blockquote>
-<p>
-<ins><i>Returns:</i> <tt>x</tt>.</ins>
-</p>
-</blockquote>
-</blockquote>
-
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="703"></a>703. <tt>map::at()</tt> need a complexity specification</h3>
-<p><b>Section:</b> 23.3.1.2 [map.access] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-07-03</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#map.access">issues</a> in [map.access].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>map::at()</tt> need a complexity specification.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following to the specification of <tt>map::at()</tt>, 23.3.1.2 [map.access]:
-</p>
-<blockquote>
-<p>
-<i>Complexity:</i> logarithmic.
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="705"></a>705. type-trait <tt>decay</tt> incompletely specified</h3>
-<p><b>Section:</b> 20.5.7 [meta.trans.other] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The current working draft has a type-trait <tt>decay</tt> in 20.5.7 [meta.trans.other].
-</p>
-
-<p>
-Its use is to turn C++03 pass-by-value parameters into efficient C++0x
-pass-by-rvalue-reference parameters. However, the current definition
-introduces an incompatible change where the cv-qualification of the
-parameter type is retained. The deduced type should loose such
-cv-qualification, as pass-by-value does.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.5.7 [meta.trans.other] change the last sentence:
-</p>
-
-<blockquote><p>
-Otherwise the member typedef <tt>type</tt> equals <tt><ins>remove_cv&lt;</ins>U<ins>&gt;::type</ins></tt>.
-</p></blockquote>
-
-<p>
-In 20.4.1.3 [tuple.creation]/1 change:
-</p>
-
-<blockquote><p>
-<del>where each <tt>Vi</tt> in <tt>VTypes</tt> is <tt>X&amp;</tt> if, for the
-corresponding type <tt>Ti</tt> in <tt>Types</tt>,
-<tt>remove_cv&lt;remove_reference&lt;Ti&gt;::type&gt;::type</tt> equals
-<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
-<tt>decay&lt;Ti&gt;::type</tt>.</del>
-<ins>Let <tt>Ui</tt> be <tt>decay&lt;Ti&gt;::type</tt> for each
-<tt>Ti</tt> in <tt>Types</tt>. Then each <tt>Vi</tt> in <tt>VTypes</tt>
-is <tt>X&amp;</tt> if <tt>Ui</tt> equals
-<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
-<tt>Ui</tt>.</ins>
-</p></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="706"></a>706. <tt>make_pair()</tt> should behave as <tt>make_tuple()</tt> wrt. <tt>reference_wrapper()</tt></h3>
-<p><b>Section:</b> 20.2.3 [pairs] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2007-07-08</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#pairs">issues</a> in [pairs].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The current draft has <tt>make_pair()</tt> in 20.2.3 [pairs]/16
-and <tt>make_tuple()</tt> in 20.4.1.3 [tuple.creation].
-<tt>make_tuple()</tt> detects the presence of
-<tt>reference_wrapper&lt;X&gt;</tt> arguments and "unwraps" the reference in
-such cases. <tt>make_pair()</tt> would OTOH create a
-<tt>reference_wrapper&lt;X&gt;</tt> member. I suggest that the two
-functions are made to behave similar in this respect to minimize
-confusion.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.2 [utility] change the synopsis for make_pair() to read
-</p>
-
-<blockquote><pre>template &lt;class T1, class T2&gt;
- pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>, <del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt; make_pair(T1&amp;&amp;, T2&amp;&amp;);
-</pre></blockquote>
-
-<p>
-In 20.2.3 [pairs]/16 change the declaration to match the above synopsis.
-Then change the 20.2.3 [pairs]/17 to:
-</p>
-
-<blockquote>
-<p>
-<i>Returns:</i> <tt>pair&lt;<del>typename decay&lt;T1&gt;::type</del> <ins>V1</ins>,<del>typename decay&lt;T2&gt;::type</del> <ins>V2</ins>&gt;(forward&lt;T1&gt;(x),forward&lt;T2&gt;(y))</tt> <ins>where <tt>V1</tt> and
-<tt>V2</tt> are determined as follows: Let <tt>Ui</tt> be
-<tt>decay&lt;Ti&gt;::type</tt> for each <tt>Ti</tt>. Then each
-<tt>Vi</tt> is <tt>X&amp;</tt> if <tt>Ui</tt> equals
-<tt>reference_wrapper&lt;X&gt;</tt>, otherwise <tt>Vi</tt> is
-<tt>Ui</tt>.</ins>
-</p>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="710"></a>710. Missing postconditions</h3>
-<p><b>Section:</b> 20.7.12.2 [util.smartptr.shared] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Peter Dimov <b>Date:</b> 2007-08-24</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-A discussion on
-<a href="http://groups.google.com/group/comp.std.c++/browse_frm/thread/8e89dceb35cd7971">comp.std.c++</a>
-has identified a contradiction in the <tt>shared_ptr</tt> specification.
-The <tt>shared_ptr</tt> move constructor and the cast functions are
-missing postconditions for the <tt>get()</tt> accessor.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Move to "ready", adopting the first (Peter's) proposed resolution.
-</p>
-<p>
-Note to the project editor: there is an editorial issue here. The
-wording for the postconditions of the casts is slightly awkward, and the
-editor should consider rewording "If w is the return value...", e. g. as
-"For a return value w...".
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to 20.7.12.2.1 [util.smartptr.shared.const]:
-</p>
-
-<blockquote>
-<pre>shared_ptr(shared_ptr&amp;&amp; r);
-template&lt;class Y&gt; shared_ptr(shared_ptr&lt;Y&gt;&amp;&amp; r);
-</pre>
-<blockquote>
-<p>
-<i>Postconditions:</i> <tt>*this</tt> shall contain the old value of <tt>r</tt>. <tt>r</tt>
-shall be empty. <ins><tt>r.get() == 0</tt>.</ins>
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-Add to 20.7.12.2.10 [util.smartptr.shared.cast]:
-</p>
-
-<blockquote>
-<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; static_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
-</pre>
-<blockquote>
-<p>
-<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
-<tt>w.get() == static_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
-</p>
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; dynamic_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
-</pre>
-<blockquote>
-<p>
-<ins><i>Postconditions:</i> If <tt>w</tt> is the return value, <tt>w.get() == dynamic_cast&lt;T*&gt;(r.get())</tt>.</ins>
-</p>
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>template&lt;class T, class U&gt; shared_ptr&lt;T&gt; const_pointer_cast(shared_ptr&lt;U&gt; const&amp; r);
-</pre>
-<blockquote>
-<p>
-<ins><i>Postconditions:</i> If <tt>w</tt> is the return value,
-<tt>w.get() == const_cast&lt;T*&gt;(r.get()) &amp;&amp; w.use_count() == r.use_count()</tt>.</ins>
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-Alberto Ganesh Barbati has written an
-<a href="http://barbati.net/c++/shared_ptr.pdf">alternative proposal</a>
-where he suggests (among other things) that the casts be respecified in terms of
-the aliasing constructor as follows:
-</p>
-
-<p>
-Change 20.7.12.2.10 [util.smartptr.shared.cast]:
-</p>
-
-<blockquote>
-<p>
--2- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
-shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
-object that stores <tt>static_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
-<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, static_cast&lt;T*&gt;(r.get())</tt>.</ins>
-</p>
-</blockquote>
-
-<blockquote>
-<p>
--6- <i>Returns:</i>
-</p>
-<ul>
-<li><del>When <tt>dynamic_cast&lt;T*&gt;(r.get())</tt> returns a nonzero value,
-a <tt>shared_ptr&lt;T&gt;</tt> object that stores a copy
-of it and <i>shares ownership</i> with <tt>r</tt>;</del></li>
-<li><del>Otherwise, an <i>empty</i> <tt>shared_ptr&lt;T&gt;</tt> object.</del></li>
-<li><ins>If <tt>p = dynamic_cast&lt;T*&gt;(r.get())</tt> is a non-null pointer, <tt>shared_ptr&lt;T&gt;(r, p);</tt></ins></li>
-<li><ins>Otherwise, <tt>shared_ptr&lt;T&gt;()</tt>.</ins></li>
-</ul>
-</blockquote>
-
-<blockquote>
-<p>
--10- <i>Returns:</i> <del>If <tt>r</tt> is empty, an <tt>empty
-shared_ptr&lt;T&gt;;</tt> otherwise, a <tt>shared_ptr&lt;T&gt;</tt>
-object that stores <tt>const_cast&lt;T*&gt;(r.get())</tt> and shares ownership with
-<tt>r</tt>.</del> <ins><tt>shared_ptr&lt;T&gt;(r, const_cast&lt;T*&gt;(r.get())</tt>.</ins>
-</p>
-</blockquote>
-
-<p>
-This takes care of the missing postconditions for the casts by bringing
-in the aliasing constructor postcondition "by reference".
-</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="712"></a>712. <tt>seed_seq::size</tt> no longer useful</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Marc Paterno <b>Date:</b> 2007-08-25</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-One of the motivations for incorporating <tt>seed_seq::size()</tt>
-was to simplify the wording
-in other parts of 26.4 [rand].
-As a side effect of resolving related issues,
-all such references
-to <tt>seed_seq::size()</tt> will have been excised.
-More importantly,
-the present specification is contradictory,
-as "The number of 32-bit units the object can deliver"
-is not the same as "the result of <tt>v.size()</tt>."
-</p>
-
-<p>
-See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2391.pdf">N2391</a> and
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>
-for some further discussion.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Adopt the proposed resolution in
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2423.pdf">N2423</a>.
-</p>
-
-
-<p><i>[
-Kona (2007): The LWG adopted the proposed resolution of N2423 for this issue.
-The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona.
-]</i></p>
-
-
-
-
-
-<hr>
-<h3><a name="715"></a>715. <tt>minmax_element</tt> complexity is too lax</h3>
-<p><b>Section:</b> 25.3.7 [alg.min.max] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Matt Austern <b>Date:</b> 2007-08-30</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#alg.min.max">issues</a> in [alg.min.max].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The complexity for <tt>minmax_element</tt> (25.3.7 [alg.min.max] par 16) says "At most <tt>max(2 *
-(last - first ) - 2, 0)</tt> applications of the corresponding comparisons",
-i.e. the worst case complexity is no better than calling <tt>min_element</tt> and
-<tt>max_element</tt> separately. This is gratuitously inefficient. There is a
-well known technique that does better: see section 9.1 of CLRS
-(Introduction to Algorithms, by Cormen, Leiserson, Rivest, and Stein).
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 25.3.7 [alg.min.max] to:
-</p>
-
-<blockquote>
-<pre>template&lt;class ForwardIterator&gt;
- pair&lt;ForwardIterator, ForwardIterator&gt;
- minmax_element(ForwardIterator first , ForwardIterator last);
-template&lt;class ForwardIterator, class Compare&gt;
- pair&lt;ForwardIterator, ForwardIterator&gt;
- minmax_element(ForwardIterator first , ForwardIterator last , Compare comp);
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> <tt>make_pair(m, M)</tt>, where <tt>m</tt> is
-<del><tt>min_element(first, last)</tt> or <tt>min_element(first, last,
-comp)</tt></del> <ins>the first iterator in <tt>[first,
-last)</tt> such that no iterator in the range refers to a smaller element,</ins> and
-<ins>where</ins> <tt>M</tt> is <del><tt>max_element(first, last)</tt> or
-<tt>max_element(first, last, comp)</tt></del> <ins>the last iterator
-in <tt>[first, last)</tt> such that no iterator in the range refers to a larger element</ins>.
-</p>
-<p>
-<i>Complexity:</i> At most <del><tt>max(2 * (last - first ) - 2, 0)</tt></del>
-<ins><tt>max(&#8970;(3/2) (N-1)&#8971;, 0)</tt></ins> applications of the
-corresponding <del>comparisons</del> <ins>predicate, where <tt>N</tt> is <tt>distance(first, last)</tt></ins>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="722"></a>722. Missing [c.math] functions <tt>nanf</tt> and <tt>nanl</tt></h3>
-<p><b>Section:</b> 26.7 [c.math] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2007-08-27</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#c.math">issues</a> in [c.math].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-In the listing of 26.7 [c.math], table 108: Header <tt>&lt;cmath&gt;</tt> synopsis I miss
-the following C99 functions (from 7.12.11.2):
-</p>
-
-<blockquote><pre>float nanf(const char *tagp);
-long double nanl(const char *tagp);
-</pre></blockquote>
-
-<p>
-(Note: These functions cannot be overloaded and they are also not
-listed anywhere else)
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 26.7 [c.math], table 108, section "Functions", add <tt>nanf</tt> and <tt>nanl</tt>
-just after the existing entry <tt>nan</tt>.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="740"></a>740. Please remove <tt>*_ptr&lt;T[N]&gt;</tt></h3>
-<p><b>Section:</b> 20.7.11.4 [unique.ptr.compiletime] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Herb Sutter <b>Date:</b> 2007-10-04</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Please don't provide <tt>*_ptr&lt;T[N]&gt;</tt>. It doesn't enable any useful
-bounds-checking (e.g., you could imagine that doing <tt>op++</tt> on a
-<tt>shared_ptr&lt;T[N]&gt;</tt> yields a <tt>shared_ptr&lt;T[N-1]&gt;</tt>, but that promising path
-immediately falters on <tt>op--</tt> which can't reliably dereference because we
-don't know the lower bound). Also, most buffers you'd want to point to
-don't have a compile-time known size.
-</p>
-
-<p>
-To enable any bounds-checking would require run-time information, with
-the usual triplet: base (lower bound), current offset, and max offset
-(upper bound). And I can sympathize with the point of view that you
-wouldn't want to require this on <tt>*_ptr</tt> itself. But please let's not
-follow the <tt>&lt;T[N]&gt;</tt> path, especially not with additional functions to
-query the bounds etc., because this sets wrong user expectations by
-embarking on a path that doesn't go all the way to bounds checking as it
-seems to imply.
-</p>
-
-<p>
-If bounds checking is desired, consider a <tt>checked_*_ptr</tt> instead (e.g.,
-<tt>checked_shared_ptr</tt>). And make the interfaces otherwise identical so that
-user code could easily <tt>#define/typedef</tt> between prepending <tt>checked_</tt> on
-debug builds and not doing so on release builds (for example).
-</p>
-
-<p>
-Note that some may object that <tt>checked_*_ptr</tt> may seem to make the smart
-pointer more like <tt>vector</tt>, and we don't want two ways to spell <tt>vector</tt>. I
-don't agree, but if that were true that would be another reason to
-remove <tt>*_ptr&lt;T[N]&gt;</tt> which equally makes the smart pointer more like
-<tt>std::array.</tt> :-)
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>Suggestion that fixed-size array instantiations are going to fail at
-compile time anyway (if we remove specialization) due to pointer decay,
-at least that appears to be result from available compilers.
-</p>
-<p>
-So concerns about about requiring static_assert seem unfounded.
-</p>
-<p>After a little more experimentation with compiler, it appears that
-fixed size arrays would only work at all if we supply these explicit
-specialization. So removing them appears less breaking than originally
-thought.
-</p>
-<p>
-straw poll unanimous move to Ready.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis under 20.7.11 [unique.ptr] p2:
-</p>
-
-<blockquote><pre>...
-template&lt;class T&gt; struct default_delete;
-template&lt;class T&gt; struct default_delete&lt;T[]&gt;;
-<del>template&lt;class T, size_t N&gt; struct default_delete&lt;T[N]&gt;;</del>
-
-template&lt;class T, class D = default_delete&lt;T&gt;&gt; class unique_ptr;
-template&lt;class T, class D&gt; class unique_ptr&lt;T[], D&gt;;
-<del>template&lt;class T, class D, size_t N&gt; class unique_ptr&lt;T[N], D&gt;;</del>
-...
-</pre></blockquote>
-
-<p>
-Remove the entire section 20.7.11.1.3 [unique.ptr.dltr.dflt2] <b><tt>default_delete&lt;T[N]&gt;</tt></b>.
-</p>
-
-<p>
-Remove the entire section 20.7.11.4 [unique.ptr.compiletime] <b><tt>unique_ptr</tt> for array objects with a compile time length</b>
-and its subsections: 20.7.11.4.1 [unique.ptr.compiletime.dtor], 20.7.11.4.2 [unique.ptr.compiletime.observers],
-20.7.11.4.3 [unique.ptr.compiletime.modifiers].
-</p>
-
-
-
-
-
-
-<hr>
-<h3><a name="743"></a>743. rvalue <tt>swap</tt> for <tt>shared_ptr</tt></h3>
-<p><b>Section:</b> 20.7.12.2.9 [util.smartptr.shared.spec] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Howard Hinnant <b>Date:</b> 2007-10-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-When the LWG looked at <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#674">674</a> in Kona the following note was made:
-</p>
-
-<blockquote><p>
-We may need to open an issue to deal with the question of
-whether <tt>shared_ptr</tt> needs an rvalue <tt>swap</tt>.
-</p></blockquote>
-
-<p>
-This issue was opened in response to that note.
-</p>
-
-<p>
-I believe allowing rvalue <tt>shared_ptr</tt>s to <tt>swap</tt> is both
-appropriate, and consistent with how other library components are currently specified.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Concern that the three signatures for swap is needlessly complicated,
-but this issue merely brings shared_ptr into equal complexity with the
-rest of the library. Will open a new issue for concern about triplicate
-signatures.
-</p>
-<p>
-Adopt issue as written.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 20.7.12.2 [util.smartptr.shared]:
-</p>
-
-<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
-...
-template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
-<ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
-template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
-</pre></blockquote>
-
-<p>
-Change 20.7.12.2.4 [util.smartptr.shared.mod]:
-</p>
-
-<blockquote><pre>void swap(shared_ptr&amp;<ins>&amp;</ins> r);
-</pre></blockquote>
-
-<p>
-Change 20.7.12.2.9 [util.smartptr.shared.spec]:
-</p>
-
-<blockquote><pre>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp; b);
-<ins>template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp;&amp; a, shared_ptr&lt;T&gt;&amp; b);
-template&lt;class T&gt; void swap(shared_ptr&lt;T&gt;&amp; a, shared_ptr&lt;T&gt;&amp;&amp; b);</ins>
-</pre></blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="744"></a>744. What is the lifetime of an exception pointed to by an exception_ptr?</h3>
-<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Without some lifetime guarantee, it is hard to know how this type can be
-used. Very specifically, I don't see how the current wording would
-guarantee and exception_ptr caught at the end of one thread could be safely
-stored and rethrown in another thread - the original motivation for this
-API.
-</p>
-<p>
-(Peter Dimov agreed it should be clearer, maybe a non-normative note to
-explain?)
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Agree the issue is real.
-</p>
-<p>
-Intent is lifetime is similar to a shared_ptr (and we might even want to
-consider explicitly saying that it is a shared_ptr&lt; unspecified type &gt;).
-</p>
-<p>
-We expect that most implementations will use shared_ptr, and the
-standard should be clear that the exception_ptr type is intended to be
-something whose semantics are smart-pointer-like so that the user does
-not need to worry about lifetime management. We still need someone to
-draught those words - suggest emailing Peter Dimov.
-</p>
-<p>
-Move to Open.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 18.7.5 [propagation]/7:
-</p>
-
-<blockquote>
--7- Returns: An <tt>exception_ptr</tt> object that refers to the currently
-handled exception or a copy of the currently handled exception, or a
-null <tt>exception_ptr</tt> object if no exception is being handled.
-<ins>The referenced object remains valid at least as long as there is an
-<tt>exception_ptr</tt> that refers to it.</ins>
-If the function needs to allocate memory and the attempt
-fails, it returns an <tt>exception_ptr</tt> object that refers to an instance of
-<tt>bad_alloc</tt>. It is unspecified whether the return values of two successive
-calls to <tt>current_exception</tt> refer to the same exception object. [<i>Note:</i>
-that is, it is unspecified whether <tt>current_exception</tt> creates a new copy
-each time it is called. <i>--end note</i>]
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="746"></a>746. current_exception may fail with bad_alloc</h3>
-<p><b>Section:</b> 18.7.5 [propagation] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#propagation">active issues</a> in [propagation].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#propagation">issues</a> in [propagation].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-I understand that the attempt to copy an exception may run out of memory,
-but I believe this is the only part of the standard that mandates failure
-with specifically <tt>bad_alloc</tt>, as opposed to allowing an
-implementation-defined type derived from <tt>bad_alloc</tt>. For instance, the Core
-language for a failed new expression is:
-</p>
-<blockquote>
-<p>
-Any other allocation function that fails to allocate storage shall indicate
-failure only by throwing an exception of a type that would match a handler
-(15.3) of type <tt>std::bad_alloc</tt> (18.5.2.1).
-</p>
-</blockquote>
-<p>
-I think we should allow similar freedom here (or add a blanket
-compatible-exception freedom paragraph in 17)
-</p>
-<p>
-I prefer the clause 17 approach myself, and maybe clean up any outstanding
-wording that could also rely on it.
-</p>
-<p>
-Although filed against a specific case, this issue is a problem throughout
-the library.
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Is issue bigger than library?
-</p>
-<p>
-No - Core are already very clear about their wording, which is inspiration for the issue.
-</p>
-<p>
-While not sold on the original 18.7.5 use case, the generalised 17.4.4.8 wording is the real issue.
-</p>
-<p>
-Accept the broad view and move to ready
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following exemption clause to 17.4.4.9 [res.on.exception.handling]:
-</p>
-
-<blockquote>
-A function may throw a type not listed in its <i>Throws</i> clause so long as it is
-derived from a class named in the <i>Throws</i> clause, and would be caught by an
-exception handler for the base type.
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="749"></a>749. Currently <tt>has_nothrow_copy_constructor&lt;T&gt;::value</tt> is true if T has 'a' nothrow copy constructor.</h3>
-<p><b>Section:</b> 20.5.4.3 [meta.unary.prop] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2007-10-10</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Unfortunately a class can have multiple copy constructors, and I believe to
-be useful this trait should only return true is ALL copy constructors are
-no-throw.
-</p>
-<p>
-For instance:
-</p>
-<blockquote>
-<pre>struct awkward {
- awkward( const awkward &amp; ) throw() {}
- awkward( awkward &amp; ) { throw "oops"; } };
-</pre>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 20.5.4.3 [meta.unary.prop]:
-</p>
-
-<blockquote>
-<pre>has_trivial_copy_constructor</pre>
-<blockquote>
-<tt>T</tt> is a trivial type (3.9) or a reference type or a class type <del>with a trivial copy constructor</del>
-<ins>where all copy constructors are trivial</ins> (12.8).
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>has_trivial_assign</pre>
-<blockquote>
-<tt>T</tt> is neither <tt>const</tt> nor a reference type, and <tt>T</tt> is a trivial type (3.9)
-or a class type <del>with a trivial copy assignment operator</del> <ins>where all copy assignment operators are trivial</ins> (12.8).
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>has_nothrow_copy_constructor</pre>
-<blockquote>
-<tt>has_trivial_copy_constructor&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with
-a</del> <ins>where all</ins> copy constructor<ins>s</ins> <del>that is</del> <ins>are</ins>
-known not to throw any exceptions or <tt>T</tt> is an
-array of such a class type
-</blockquote>
-</blockquote>
-
-<blockquote>
-<pre>has_nothrow_assign</pre>
-<blockquote>
-<tt>T</tt> is neither <tt>const</tt> nor a reference type, and
-<tt>has_trivial_assign&lt;T&gt;::value</tt> is <tt>true</tt> or <tt>T</tt> is a class type <del>with a</del>
-<ins>where all</ins> copy
-assignment operator<ins>s</ins> tak<ins>e</ins><del>ing</del> an lvalue of type <tt>T</tt> that is known not to
-throw any exceptions or <tt>T</tt> is an array of such a class type.
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="755"></a>755. <tt>std::vector</tt> and <tt>std:string</tt> lack explicit shrink-to-fit operations</h3>
-<p><b>Section:</b> 23.2.6.2 [vector.capacity], 21.3.4 [string.capacity] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Beman Dawes <b>Date:</b> 2007-10-31</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-A <tt>std::vector</tt> can be shrunk-to-fit via the swap idiom:
-</p>
-
-<blockquote><pre>vector&lt;int&gt; v;
-...
-v.swap(vector&lt;int&gt;(v)); // shrink to fit
-</pre>
-<blockquote><p>
-or:
-</p></blockquote>
-<pre>vector&lt;int&gt;(v).swap(v); // shrink to fit
-</pre>
-<blockquote><p>
-or:
-</p></blockquote>
-<pre>swap(v, vector&lt;int&gt;(v)); // shrink to fit
-</pre>
-</blockquote>
-
-<p>
-A non-binding request for shrink-to-fit can be made to a <tt>std::string</tt> via:
-</p>
-
-<blockquote><pre>string s;
-...
-s.reserve(0);
-</pre></blockquote>
-
-<p>
-Neither of these is at all obvious to beginners, and even some
-experienced C++ programmers are not aware that shrink-to-fit is
-trivially available.
-</p>
-<p>
-Lack of explicit functions to perform these commonly requested
-operations makes vector and string less usable for non-experts. Because
-the idioms are somewhat obscure, code readability is impaired. It is
-also unfortunate that two similar vector-like containers use different
-syntax for the same operation.
-</p>
-<p>
-The proposed resolution addresses these concerns. The proposed function
-takes no arguments to keep the solution simple and focused.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-To Class template basic_string 21.3 [basic.string] synopsis,
-Class template vector 23.2.6 [vector] synopsis, and Class
-vector&lt;bool&gt; 23.2.7 [vector.bool] synopsis, add:
-</p>
-
-<blockquote><pre>
-void shrink_to_fit();
-</pre></blockquote>
-
-<p>
-To basic_string capacity 21.3.4 [string.capacity] and vector
-capacity 23.2.6.2 [vector.capacity], add:
-</p>
-
-<blockquote>
-<pre>void shrink_to_fit();
-</pre>
-<blockquote>
-<i>Remarks:</i> <tt>shrink_to_fit</tt> is a non-binding request to reduce
-<tt>capacity()</tt> to <tt>size()</tt>. [<i>Note:</i> The request is non-binding to
-allow latitude for implementation-specific optimizations.
-<i>-- end note</i>]
-</blockquote>
-</blockquote>
-
-<p><i>[
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#850">850</a> has been added to deal with this issue with respect to <tt>deque</tt>.
-]</i></p>
-
-
-
-
-
-
-<hr>
-<h3><a name="759"></a>759. A reference is not an object</h3>
-<p><b>Section:</b> 23.1 [container.requirements] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Jens Maurer <b>Date:</b> 2007-11-06</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-23.1 [container.requirements] says:
-</p>
-
-<blockquote>
--12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No
-diagnostic required.
-</blockquote>
-
-<p>
-A reference is not an object, but this sentence appears to claim so.
-</p>
-
-<p>
-What is probably meant here:
-</p>
-<blockquote>
-An object bound to an rvalue
-reference parameter of a member function of a container shall not be
-an element of that container; no diagnostic required.
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 23.1 [container.requirements]:
-</p>
-
-<blockquote>
--12- <del>Objects passed to member functions of a container as rvalue references shall not be elements</del>
-<ins>An object bound to an rvalue
-reference parameter of a member function of a container shall not be
-an element</ins>
-of that container<del>.</del><ins>;</ins> <del>N</del><ins>n</ins>o
-diagnostic required.
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="761"></a>761. <tt>unordered_map</tt> needs an <tt>at()</tt> member function</h3>
-<p><b>Section:</b> 23.4.1.2 [unord.map.elem] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Joe Gottman <b>Date:</b> 2007-11-15</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The new member function <tt>at()</tt> was recently added to <tt>std::map()</tt>. It acts
-like <tt>operator[]()</tt>, except it throws an exception when the input key is
-not found. It is useful when the <tt>map</tt> is <tt>const</tt>, the <tt>value_type</tt> of the
-key doesn't have a default constructor, it is an error if the key is
-not found, or the user wants to avoid accidentally adding an element to
-the map. For exactly these same reasons, <tt>at()</tt> would be equally useful
-in <tt>std::unordered_map</tt>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the following functions to the definition of <tt>unordered_map</tt> under "lookup" (23.4.1 [unord.map]):
-</p>
-
-<blockquote><pre>mapped_type&amp; at(const key_type&amp; k);
-const mapped_type &amp;at(const key_type &amp;k) const;
-</pre></blockquote>
-
-<p>
-Add the following definitions to 23.4.1.2 [unord.map.elem]:
-</p>
-
-<blockquote>
-<pre>mapped_type&amp; at(const key_type&amp; k);
-const mapped_type &amp;at(const key_type &amp;k) const;
-</pre>
-<blockquote>
-<p>
-<i>Returns:</i> A reference to <tt>x.second</tt>, where <tt>x</tt> is the (unique) element
-whose key is equivalent to <tt>k</tt>.
-</p>
-<p>
-<i>Throws:</i> An exception object of type <tt>out_of_range</tt> if no such element
-is present.
-</p>
-</blockquote>
-</blockquote>
-
-<p><i>[
-Bellevue: Editorial note: the "(unique)" differs from map.
-]</i></p>
-
-
-
-
-
-
-
-<hr>
-<h3><a name="766"></a>766. Inconsistent exception guarantees between ordered and unordered associative containers</h3>
-<p><b>Section:</b> 23.1 [container.requirements], 23.1.5.1 [unord.req.except] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Ion Gaztaaga <b>Date:</b> 2007-12-22</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-23.1 [container.requirements]p10 states:
-</p>
-
-<blockquote>
-<p>
-Unless otherwise specified (see 23.2.2.3 and 23.2.5.4) all container types defined in this clause meet the following
-additional requirements:
-</p>
-<ul>
-
-<li>[...]</li>
-
-<li>no <tt>erase()</tt>, <tt>pop_back()</tt> or <tt>pop_front()</tt> function throws an exception.</li>
-
-</ul>
-</blockquote>
-
-<p>
-23.2.2.3 [deque.modifiers] and 23.2.6.4 [vector.modifiers] offer
-additional guarantees for <tt>deque</tt>/<tt>vector insert()</tt> and
-<tt>erase()</tt> members. However, 23.1 [container.requirements]p10
-does not mention 23.1.5.1 [unord.req.except] that specifies exception
-safety guarantees
-for unordered containers. In addition, 23.1.5.1 [unord.req.except]p1
-offers the following guaratee for
-<tt>erase()</tt>:
-</p>
-
-<blockquote>
-No <tt>erase()</tt> function throws an exception unless that exception
-is thrown by the container's Hash or Pred object (if any).
-</blockquote>
-
-<p>
-Summary:
-</p>
-
-<p>
-According to 23.1 [container.requirements]p10 no
-<tt>erase()</tt> function should throw an exception unless otherwise
-specified. Although does not explicitly mention 23.1.5.1 [unord.req.except], this section offers additional guarantees
-for unordered containers, allowing <tt>erase()</tt> to throw if
-predicate or hash function throws.
-</p>
-
-<p>
-In contrast, associative containers have no exception safety guarantees
-section so no <tt>erase()</tt> function should throw, <em>including
-<tt>erase(k)</tt></em> that needs to use the predicate function to
-perform its work. This means that the predicate of an associative
-container is not allowed to throw.
-</p>
-
-<p>
-So:
-</p>
-
-<ol>
-<li>
-<tt>erase(k)</tt> for associative containers is not allowed to throw. On
-the other hand, <tt>erase(k)</tt> for unordered associative containers
-is allowed to throw.
-</li>
-<li>
-<tt>erase(q)</tt> for associative containers is not allowed to throw. On
-the other hand, <tt>erase(q)</tt> for unordered associative containers
-is allowed to throw if it uses the hash or predicate.
-</li>
-<li>
-To fulfill 1), predicates of associative containers are not allowed to throw.
-Predicates of unordered associative containers are allowed to throw.
-</li>
-<li>
-2) breaks a widely used programming pattern (flyweight pattern) for
-unordered containers, where objects are registered in a global map in
-their constructors and unregistered in their destructors. If <tt>erase(q)</tt> is
-allowed to throw, the destructor of the object would need to rethrow the
-exception or swallow it, leaving the object registered.
-</li>
-</ol>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Create a new sub-section of 23.1.4 [associative.reqmts] (perhaps [associative.req.except]) titled "Exception
-safety guarantees".
-</p>
-
-<blockquote>
-<p>
-1 For associative containers, no <tt>clear()</tt> function throws an exception.
-<tt>erase(k)</tt> does not throw an exception unless that exception is thrown by
-the container's Pred object (if any).
-</p>
-
-<p>
-2 For associative containers, if an exception is thrown by any operation
-from within an <tt>insert()</tt> function inserting a single element, the
-<tt>insert()</tt> function has no effect.
-</p>
-
-<p>
-3 For associative containers, no <tt>swap</tt> function throws an exception
-unless that exception is thrown by the copy constructor or copy
-assignment operator of the container's Pred object (if any).
-</p>
-</blockquote>
-
-<p>
-Change 23.1.5.1 [unord.req.except]p1:
-</p>
-
-<blockquote>
-For unordered associative containers, no <tt>clear()</tt> function
-throws an exception. <del>No</del> <tt>erase(<ins>k</ins>)</tt>
-<del>function</del> <ins>does not</ins> throw<del>s</del> an exception
-unless that exception is thrown by the container's Hash or Pred object
-(if any).
-</blockquote>
-
-<p>
-Change 23.1 [container.requirements]p10 to add references to new sections:
-</p>
-
-<blockquote>
-Unless otherwise specified (see [deque.modifiers]<ins>,</ins>
-<del>and</del> [vector.modifiers]<ins>, [associative.req.except],
-[unord.req.except]</ins>) all container types defined in this clause meet
-the following additional requirements:
-</blockquote>
-
-<p>
-Change 23.1 [container.requirements]p10 referring to <tt>swap</tt>:
-</p>
-
-<blockquote>
-<ul>
-<li>
-no <tt>swap()</tt> function throws an exception<del> unless that exception is thrown
-by the copy constructor or assignment operator of the container's
-Compare object (if any; see [associative.reqmts])</del>.
-</li>
-</ul>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="768"></a>768. Typos in [atomics]?</h3>
-<p><b>Section:</b> 29.3.3 [atomics.types.generic] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Alberto Ganesh Barbati <b>Date:</b> 2007-12-28</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-in the latest publicly available draft, paper
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf">N2641</a>,
-in section 29.3.3 [atomics.types.generic], the following specialization of the template
-<tt>atomic&lt;&gt;</tt> is provided for pointers:
-</p>
-
-<blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address {
- T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
- T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
-
- atomic() = default;
- constexpr explicit atomic(T);
- atomic(const atomic&amp;) = delete;
- atomic&amp; operator=(const atomic&amp;) = delete;
-
- T* operator=(T*) volatile;
- T* operator++(int) volatile;
- T* operator--(int) volatile;
- T* operator++() volatile;
- T* operator--() volatile;
- T* operator+=(ptrdiff_t) volatile;
- T* operator-=(ptrdiff_t) volatile;
-};
-</pre></blockquote>
-
-<p>
-First of all, there is a typo in the non-default constructor which
-should take a <tt>T*</tt> rather than a <tt>T</tt>.
-</p>
-
-<p>
-As you can see, the specialization redefine and therefore hide a few
-methods from the base class <tt>atomic_address</tt>, namely <tt>fetch_add</tt>, <tt>fetch_sub</tt>,
-<tt>operator=</tt>, <tt>operator+=</tt> and <tt>operator-=</tt>. That's good, but... what happened
-to the other methods, in particular these ones:
-</p>
-
-<blockquote><pre>void store(T*, memory_order = memory_order_seq_cst) volatile;
-T* load( memory_order = memory_order_seq_cst ) volatile;
-T* swap( T*, memory_order = memory_order_seq_cst ) volatile;
-bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;
-bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;
-</pre></blockquote>
-
-<p>
-By reading paper
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html">N2427 "C++ Atomic Types and Operations"</a>,
-I see that the
-definition of the specialization <tt>atomic&lt;T*&gt;</tt> matches the one in the
-draft, but in the example implementation the methods <tt>load()</tt>, <tt>swap()</tt>
-and <tt>compare_swap()</tt> are indeed present.
-</p>
-
-<p>
-Strangely, the example implementation does not redefine the method
-<tt>store()</tt>. It's true that a <tt>T*</tt> is always convertible to <tt>void*</tt>, but not
-hiding the <tt>void*</tt> signature from the base class makes the class
-error-prone to say the least: it lets you assign pointers of any type to
-a <tt>T*</tt>, without any hint from the compiler.
-</p>
-
-<p>
-Is there a true intent to remove them from the specialization or are
-they just missing from the definition because of a mistake?
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-The proposed revisions are accepted.
-</p>
-<p>
-Further discussion: why is the ctor labeled "constexpr"? Lawrence said
-this permits the object to be statically initialized, and that's
-important because otherwise there would be a race condition on
-initialization.
-</p>
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change the synopsis in 29.3.3 [atomics.types.generic]:
-</p>
-
-<blockquote><pre>template &lt;class T&gt; struct atomic&lt;T*&gt; : atomic_address {
- <ins>void store(T*, memory_order = memory_order_seq_cst) volatile;</ins>
- <ins>T* load( memory_order = memory_order_seq_cst ) volatile;</ins>
- <ins>T* swap( T*, memory_order = memory_order_seq_cst ) volatile;</ins>
- <ins>bool compare_swap( T*&amp;, T*, memory_order, memory_order ) volatile;</ins>
- <ins>bool compare_swap( T*&amp;, T*, memory_order = memory_order_seq_cst ) volatile;</ins>
-
- T* fetch_add(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
- T* fetch_sub(ptrdiff_t, memory_order = memory_order_seq_cst) volatile;
-
- atomic() = default;
- constexpr explicit atomic(T<ins>*</ins>);
- atomic(const atomic&amp;) = delete;
- atomic&amp; operator=(const atomic&amp;) = delete;
-
- T* operator=(T*) volatile;
- T* operator++(int) volatile;
- T* operator--(int) volatile;
- T* operator++() volatile;
- T* operator--() volatile;
- T* operator+=(ptrdiff_t) volatile;
- T* operator-=(ptrdiff_t) volatile;
-};
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="770"></a>770. std::function should use rvalue swap</h3>
-<p><b>Section:</b> 20.6.15 [func.wrap] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-01-10</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-It is expected that typical implementations of <tt>std::function</tt> will
-use dynamic memory allocations at least under given conditions,
-so it seems appropriate to change the current lvalue swappabilty of
-this class to rvalue swappability.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 20.6 [function.objects], header <tt>&lt;functional&gt;</tt> synopsis, just below of
-</p>
-
-<blockquote><pre>template&lt;class R, class... ArgTypes&gt;
- void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
-<ins>template&lt;class R, class... ArgTypes&gt;
- void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
-template&lt;class R, class... ArgTypes&gt;
- void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
-</pre></blockquote>
-
-<p>
-In 20.6.15.2 [func.wrap.func] class <tt>function</tt> definition, change
-</p>
-
-<blockquote><pre>void swap(function&amp;<ins>&amp;</ins>);
-</pre></blockquote>
-
-<p>
-In 20.6.15.2 [func.wrap.func], just below of
-</p>
-
-<blockquote><pre>template &lt;class R, class... ArgTypes&gt;
- void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
-<ins>template &lt;class R, class... ArgTypes&gt;
- void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp;, function&lt;R(ArgTypes...)&gt;&amp;);
-template &lt;class R, class... ArgTypes&gt;
- void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;&amp;);</ins>
-</pre></blockquote>
-
-<p>
-In 20.6.15.2.2 [func.wrap.func.mod] change
-</p>
-
-<blockquote><pre>void swap(function&amp;<ins>&amp;</ins> other);
-</pre></blockquote>
-
-<p>
-In 20.6.15.2.7 [func.wrap.func.alg] add the two overloads
-</p>
-
-<blockquote><pre><ins>template&lt;class R, class... ArgTypes&gt;
- void swap(function&lt;R(ArgTypes...)&gt;&amp;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2);
-template&lt;class R, class... ArgTypes&gt;
- void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp;&amp; f2);</ins>
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="775"></a>775. Tuple indexing should be unsigned?</h3>
-<p><b>Section:</b> 20.4.1.4 [tuple.helper] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 2008-01-16</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The tuple element access API identifies the element in the sequence
-using signed integers, and then goes on to enforce the requirement that
-I be &gt;= 0. There is a much easier way to do this - declare I as
-<tt>unsigned</tt>.
-</p>
-<p>
-In fact the proposal is to use <code>std::size_t</code>, matching the type used in the <tt>tuple_size</tt> API.
-</p>
-<p>
-A second suggestion is that it is hard to imagine an API that deduces
-and index at compile time and returns a reference throwing an exception.
-Add a specific <em>Throws:</em> Nothing paragraph to each element
-access API.
-</p>
-<p>
-In addition to <code>tuple</code>, update the API applies to
-<code>pair</code> and <code>array</code>, and should be updated
-accordingly.
-</p>
-
-<p>
-A third observation is that the return type of the <code>get</code>
-functions for <code>std::pair</code> is pseudo-code, but it is not
-clearly marked as such. There is actually no need for pseudo-code as
-the return type can be specified precisely with a call to
-<code>tuple_element</code>. This is already done for
-<code>std::tuple</code>, and <code>std::array</code> does not have a
-problem as all elements are of type <code>T</code>.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Update header &lt;utility&gt; synopsis in 20.2 [utility]
-</p>
-<pre><em>// 20.2.3, tuple-like access to pair:</em>
-template &lt;class T&gt; class tuple_size;
-template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element;
-
-template &lt;class T1, class T2&gt; struct tuple_size&lt;std::pair&lt;T1, T2&gt; &gt;;
-template &lt;class T1, class T2&gt; struct tuple_element&lt;0, std::pair&lt;T1, T2&gt; &gt;;
-template &lt;class T1, class T2&gt; struct tuple_element&lt;1, std::pair&lt;T1, T2&gt; &gt;;
-
-template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
- <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(std::pair&lt;T1, T2&gt;&amp;);
-template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
- const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const std::pair&lt;T1, T2&gt;&amp;);
-</pre>
-<p>
-Update <strong>20.2.3 [pairs] Pairs</strong>
-</p>
-<pre>template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
- <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(pair&lt;T1, T2&gt;&amp;);
-template&lt;<del>int</del><ins>size_t</ins> I, class T1, class T2&gt;
- const <del>P</del><ins>typename tuple_element&lt;I, std::pair&lt;T1, T2&gt; &gt;::type </ins>&amp; get(const pair&lt;T1, T2&gt;&amp;);
-</pre>
-<p>
-<del>24 <em>Return type:</em> If <code>I == 0</code> then <code>P</code> is <code>T1</code>, if <code>I == 1</code> then <code>P</code> is <code>T2</code>, and otherwise the program is ill-formed.</del>
-</p>
-<p>
-25 <em>Returns:</em> If <code>I == 0</code> returns <code>p.first</code>, <del>otherwise</del> <ins>if <code>I == 1</code></ins> returns <code>p.second</code><ins>, and otherwise the program is ill-formed</ins>.
-</p>
-<p>
-<ins><em>Throws:</em> Nothing.</ins>
-</p>
-
-
-<p>
-Update header &lt;tuple&gt; synopsis in 20.4 [tuple] with a APIs as below:
-</p>
-<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// undefined</em>
-template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt; class tuple_element&lt;I, tuple&lt;Types...&gt; &gt;;
-
-<em>// 20.3.1.4, element access:</em>
-template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
- typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp;);
-template &lt;<del>int</del><ins>size_t</ins> I, class ... types&gt;
- typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp;);
-</pre>
-
-<p>
-Update <strong>20.4.1.4 [tuple.helper] Tuple helper classes</strong>
-</p>
-<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... Types&gt;
-class tuple_element&lt;I, tuple&lt;Types...&gt; &gt; {
-public:
- typedef TI type;
-};</pre>
-<p>
-1 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
-</p>
-<p>
-2 <em>Type:</em> <code>TI</code> is the type of the <code>I</code>th element of <code>Types</code>, where indexing is zero-based.
-</p>
-<p>
-Update <strong>20.4.1.5 [tuple.elem] Element access</strong>
-</p>
-<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types &gt;
-typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type&amp; get(tuple&lt;Types...&gt;&amp; t);
-</pre>
-1 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
-<p>
-2 <em>Returns:</em> A reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
-</p>
-<ins><em>Throws:</em> Nothing.</ins>
-<pre>template &lt;<del>int</del><ins>size_t</ins> I, class... types&gt;
-typename tuple_element&lt;I, tuple&lt;Types...&gt; &gt;::type const&amp; get(const tuple&lt;Types...&gt;&amp; t);
-</pre>
-<p>
-3 <em>Requires:</em> <code><del>0 &lt;= I and </del>I &lt; sizeof...(Types)</code>. The program is ill-formed if <code>I</code> is out of bounds.
-</p>
-<p>
-4 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>t</code>, where indexing is zero-based.
-</p>
-<p>
-<ins><em>Throws:</em> Nothing.</ins>
-</p>
-
-
-<p>
-Update header &lt;array&gt; synopsis in 20.2 [utility]
-</p>
-<pre>template &lt;class T&gt; class tuple_size; <em>// forward declaration</em>
-template &lt;<del>int</del><ins>size_t</ins> I, class T&gt; class tuple_element; <em>// forward declaration</em>
-template &lt;class T, size_t N&gt;
- struct tuple_size&lt;array&lt;T, N&gt; &gt;;
-template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
- struct tuple_element&lt;I, array&lt;T, N&gt; &gt;;
-template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
- T&amp; get(array&lt;T, N&gt;&amp;);
-template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt;
- const T&amp; get(const array&lt;T, N&gt;&amp;);
-</pre>
-
-<p>
-Update <strong>23.2.1.6 [array.tuple] Tuple interface to class template array</strong>
-</p>
-<pre>tuple_element&lt;<ins>size_t </ins>I, array&lt;T, N&gt; &gt;::type
-</pre>
-<p>
-3 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N.</code> The program is ill-formed if <code>I</code> is out of bounds.
-</p>
-<p>
-4 <em>Value:</em> The type <code>T</code>.
-</p>
-<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; T&amp; get(array&lt;T, N&gt;&amp; a);
-</pre>
-<p>
-5 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
-</p>
-<p>
-<em>Returns:</em> A reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
-</p>
-<p>
-<ins><em>Throws:</em> Nothing.</ins>
-</p>
-<pre>template &lt;<del>int</del><ins>size_t</ins> I, class T, size_t N&gt; const T&amp; get(const array&lt;T, N&gt;&amp; a);
-</pre>
-<p>
-6 <em>Requires:</em> <code><del>0 &lt;= </del>I &lt; N</code>. The program is ill-formed if <code>I</code> is out of bounds.
-</p>
-<p>
-7 <em>Returns:</em> A const reference to the <code>I</code>th element of <code>a</code>, where indexing is zero-based.
-</p>
-<p>
-<ins><em>Throws:</em> Nothing.</ins>
-</p>
-
-
-<p><i>[
-Bellevue: Note also that the phrase "The program is ill-formed if I is
-out of bounds" in the requires clauses are probably unnecessary, and
-could be removed at the editor's discretion. Also std:: qualification
-for pair is also unnecessary.
-]</i></p>
-
-
-
-
-<hr>
-<h3><a name="777"></a>777. Atomics Library Issue</h3>
-<p><b>Section:</b> 29.4 [atomics.types.operations] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Lawrence Crowl <b>Date:</b> 2008-01-21</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#atomics.types.operations">issues</a> in [atomics.types.operations].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The load functions are defined as
-</p>
-
-<blockquote><pre>C atomic_load(volatile A* object);
-C atomic_load_explicit(volatile A* object, memory_order);
-C A::load(memory_order order = memory_order_seq_cst) volatile;
-</pre></blockquote>
-
-<p>
-which prevents their use in <tt>const</tt> contexts.
-</p>
-
-<p><i>[
-post Bellevue Peter adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#777">777</a> suggests making <tt>atomic_load</tt> operate on <tt>const</tt> objects. There is a
-subtle point here. Atomic loads do not generally write to the object, except
-potentially for the <tt>memory_order_seq_cst</tt> constraint. Depending on the
-architecture, a dummy write with the same value may be required to be issued
-by the atomic load to maintain sequential consistency. This, in turn, may
-make the following code:
-</p>
-
-<blockquote><pre>const atomic_int x{};
-
-int main()
-{
- x.load();
-}
-</pre></blockquote>
-
-<p>
-dump core under a straightforward implementation that puts const objects in
-a read-only section.
-</p>
-<p>
-There are ways to sidestep the problem, but it needs to be considered.
-</p>
-<p>
-The tradeoff is between making the data member of the atomic types
-mutable and requiring the user to explicitly mark atomic members as
-mutable, as is already the case with mutexes.
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add the <tt>const</tt> qualifier to <tt>*object</tt> and <tt>*this</tt>.
-</p>
-
-<blockquote><pre>C atomic_load(<ins>const</ins> volatile A* object);
-C atomic_load_explicit(<ins>const</ins> volatile A* object, memory_order);
-C A::load(memory_order order = memory_order_seq_cst) <ins>const</ins> volatile;
-</pre></blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="778"></a>778. std::bitset does not have any constructor taking a string literal</h3>
-<p><b>Section:</b> 23.3.5.1 [bitset.cons] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 2008-01-24</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#bitset.cons">issues</a> in [bitset.cons].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Duplicate of:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116">116</a></p>
-<p><b>Discussion:</b></p>
-<p>
-A small issue with <tt>std::bitset</tt>: it does not have any constructor
-taking a string literal, which is clumsy and looks like an oversigt when
-we tried to enable uniform use of <tt>string</tt> and <tt>const char*</tt> in the library.
-</p>
-
-<p>
-Suggestion: Add
-</p>
-
-<blockquote><pre>explicit bitset( const char* str );
-</pre></blockquote>
-
-<p>
-to std::bitset.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add to synopsis in 23.3.5 [template.bitset]
-</p>
-
-<blockquote><pre>explicit bitset( const char* str );
-</pre></blockquote>
-
-<p>
-Add to synopsis in 23.3.5.1 [bitset.cons]
-</p>
-
-<blockquote><pre>explicit bitset( const char* str );
-</pre>
-<p>
-<i>Effects:</i> Constructs a <tt>bitset</tt> as if <tt>bitset(string(str))</tt>.
-</p>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="781"></a>781. <tt>std::complex</tt> should add missing C99 functions</h3>
-<p><b>Section:</b> 26.3.7 [complex.value.ops] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-01-26</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#complex.value.ops">issues</a> in [complex.value.ops].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-A comparision of the N2461 header <tt>&lt;complex&gt;</tt> synopsis ([complex.synopsis])
-with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
-some complex functions that are missing in C++. These are:
-</p>
-
-<ol>
-<li>
-7.3.9.4: (required elements of the C99 library)<br>
-The <tt>cproj</tt> functions
-</li>
-<li>
-7.26.1: (optional elements of the C99 library)<br>
-<pre>cerf cerfc cexp2
-cexpm1 clog10 clog1p
-clog2 clgamma ctgamma
-</pre>
-</li>
-</ol>
-
-<p>
-I propose that at least the required <tt>cproj</tt> overloads are provided as equivalent
-C++ functions. This addition is easy to do in one sentence (delegation to C99
-function).
-</p>
-
-<p>
-Please note also that the current entry <tt>polar</tt>
-in 26.3.9 [cmplx.over]/1
-should be removed from the mentioned overload list. It does not make sense to require that a
-function already expecting <em>scalar</em> arguments
-should cast these arguments into corresponding
-<tt>complex&lt;T&gt;</tt> arguments, which are not accepted by
-this function.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-In 26.3.1 [complex.synopsis] add just between the declaration of <tt>conj</tt> and <tt>fabs</tt>:
-</p>
-
-<blockquote><pre>template&lt;class T&gt; complex&lt;T&gt; conj(const complex&lt;T&gt;&amp;);
-<ins>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp;);</ins>
-template&lt;class T&gt; complex&lt;T&gt; fabs(const complex&lt;T&gt;&amp;);
-</pre></blockquote>
-
-<p>
-In 26.3.7 [complex.value.ops] just after p.6 (return clause of <tt>conj</tt>) add:
-</p>
-
-<blockquote>
-<pre>template&lt;class T&gt; complex&lt;T&gt; proj(const complex&lt;T&gt;&amp; x);
-</pre>
-<blockquote>
-
-<i>Effects:</i> Behaves the same as C99 function <tt>cproj</tt>, defined in
-subclause 7.3.9.4."
-</blockquote>
-</blockquote>
-
-<p>
-In 26.3.9 [cmplx.over]/1, add one further entry <tt>proj</tt> to
-the overload list.
-</p>
-
-<blockquote>
-<p>
-The following function templates shall have additional overloads:
-</p>
-<blockquote><pre>arg norm
-conj <del>polar</del> <ins>proj</ins>
-imag real
-</pre></blockquote>
-</blockquote>
-
-
-
-
-
-
-<hr>
-<h3><a name="782"></a>782. Extended <tt>seed_seq</tt> constructor is useless</h3>
-<p><b>Section:</b> 26.4.7.1 [rand.util.seedseq] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-01-27</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.util.seedseq">active issues</a> in [rand.util.seedseq].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.util.seedseq">issues</a> in [rand.util.seedseq].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-Part of the resolution of n2423, issue 8 was the proposal to
-extend the <tt>seed_seq</tt> constructor accepting an input range
-as follows (which is now part of N2461):
-</p>
-
-<blockquote><pre>template&lt;class InputIterator,
-size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits&gt;
-seed_seq(InputIterator begin, InputIterator end);
-</pre></blockquote>
-
-<p>
-First, the expression <tt>iterator_traits&lt;InputIterator&gt;::value_type</tt>
-is invalid due to missing <tt>typename</tt> keyword, which is easy to
-fix.
-</p>
-
-<p>
-Second (and worse), while the language now supports default
-template arguments of function templates, this customization
-point via the second <tt>size_t</tt> template parameter is of no advantage,
-because <tt>u</tt> can never be deduced, and worse - because it is a
-constructor function template - it can also never be explicitly
-provided (14.8.1 [temp.arg.explicit]/7).
-</p>
-
-<p>
-The question arises, which advantages result from a compile-time
-knowledge of <tt>u</tt> versus a run time knowledge? If run time knowledge
-suffices, this parameter should be provided as normal function
-default argument [Resolution marked (A)], if compile-time knowledge
-is important, this could be done via a tagging template or more
-user-friendly via a standardized helper generator function
-(<tt>make_seed_seq</tt>), which allows this [Resolution marked (B)].
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-<p>
-Fermilab does not have a strong opinion. Would prefer to go with
-solution A. Bill agrees that solution A is a lot simpler and does the
-job.
-</p>
-<p>
-Proposed Resolution: Accept Solution A.
-</p>
-</blockquote>
-
-<p>
-Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#803">803</a> claims to make this issue moot.
-</p>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<ol type="A">
-<li>
-<p>
-In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis replace:
-</p>
-
-<blockquote><pre>class seed_seq
-{
-public:
- ...
- template&lt;class InputIterator<del>,
- size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
- seed_seq(InputIterator begin, InputIterator end<ins>,
- size_t u = numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</ins>);
- ...
-};
-</pre></blockquote>
-
-<p>
-and do a similar replacement in the member description between
-p.3 and p.4.
-</p>
-</li>
-
-<li>
-<p>
-In 26.4.7.1 [rand.util.seedseq]/2, class <tt>seed_seq</tt> synopsis <em>and</em> in the
-member description between p.3 and p.4 replace:
-</p>
-
-<blockquote><pre>template&lt;class InputIterator<del>,
- size_t u = numeric_limits&lt;iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</del>&gt;
- seed_seq(InputIterator begin, InputIterator end);
-<ins>template&lt;class InputIterator, size_t u&gt;
-seed_seq(InputIterator begin, InputIterator end, <i>implementation-defined</i> s);</ins>
-</pre></blockquote>
-
-<p>
-In 26.4.2 [rand.synopsis], header <tt>&lt;random&gt;</tt> synopsis, immediately after the
-class <tt>seed_seq</tt> declaration <em>and</em> in 26.4.7.1 [rand.util.seedseq]/2, immediately
-after the class <tt>seed_seq</tt> definition add:
-</p>
-
-<blockquote><pre>template&lt;size_t u, class InputIterator&gt;
- seed_seq make_seed_seq(InputIterator begin, InputIterator end);
-</pre></blockquote>
-
-<p>
-In 26.4.7.1 [rand.util.seedseq], just before p.5 insert two paragraphs:
-</p>
-
-<blockquote>
-<p>
-The first constructor behaves as if it would provide an
-integral constant expression <tt>u</tt> of type <tt>size_t</tt> of value
-<tt>numeric_limits&lt;typename iterator_traits&lt;InputIterator&gt;::value_type&gt;::digits</tt>.
-</p>
-<p>
-The second constructor uses an implementation-defined mechanism
-to provide an integral constant expression <tt>u</tt> of type <tt>size_t</tt> and
-is called by the function <tt>make_seed_seq</tt>.
-</p>
-</blockquote>
-
-<p>
-In 26.4.7.1 [rand.util.seedseq], just after the last paragraph add:
-</p>
-
-<blockquote>
-<pre>template&lt;size_t u, class InputIterator&gt;
- seed_seq make_seed_seq(InputIterator begin, InputIterator end);
-</pre>
-<blockquote>
-<p>
-where <tt>u</tt> is used to construct an object <tt>s</tt> of implementation-defined type.
-</p>
-<p>
-<i>Returns:</i> <tt>seed_seq(begin, end, s)</tt>;
-</p>
-</blockquote>
-</blockquote>
-
-</li>
-</ol>
-
-
-
-
-
-
-<hr>
-<h3><a name="783"></a>783. <tt>thread::id</tt> reuse</h3>
-<p><b>Section:</b> 30.2.1.1 [thread.thread.id] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Hans Boehm <b>Date:</b> 2008-02-01</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-The current working paper
-(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html">N2497</a>,
-integrated just before Bellevue) is
-not completely clear whether a given <tt>thread::id</tt> value may be reused once
-a thread has exited and has been joined or detached. Posix allows
-thread ids (<tt>pthread_t</tt> values) to be reused in this case. Although it is
-not completely clear whether this originally was the right decision, it
-is clearly the established practice, and we believe it was always the
-intent of the C++ threads API to follow Posix and allow this. Howard
-Hinnant's example implementation implicitly relies on allowing reuse
-of ids, since it uses Posix thread ids directly.
-</p>
-
-<p>
-It is important to be clear on this point, since it the reuse of thread
-ids often requires extra care in client code, which would not be
-necessary if thread ids were unique across all time. For example, a
-hash table indexed by thread id may have to be careful not to associate
-data values from an old thread with a new one that happens to reuse the
-id. Simply removing the old entry after joining a thread may not be
-sufficient, if it creates a visible window between the join and removal
-during which a new thread with the same id could have been created and
-added to the table.
-</p>
-
-<p><i>[
-post Bellevue Peter adds:
-]</i></p>
-
-
-<blockquote>
-<p>
-There is a real issue with <tt>thread::id</tt> reuse, but I urge the LWG to
-reconsider fixing this by disallowing reuse, rather than explicitly allowing
-it. Dealing with thread id reuse is an incredibly painful exercise that
-would just force the world to reimplement a non-conflicting <tt>thread::id</tt> over
-and over.
-</p>
-<p>
-In addition, it would be nice if a <tt>thread::id</tt> could be manipulated
-atomically in a lock-free manner, as motivated by the recursive lock
-example:
-</p>
-
-<p>
-<a href="http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html">http://www.decadentplace.org.uk/pipermail/cpp-threads/2006-August/001091.html</a>
-</p>
-</blockquote>
-
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Add a sentence to 30.2.1.1 [thread.thread.id]/p1:
-</p>
-
-<blockquote>
-<p>
-An object of type <code>thread::id</code> provides
-a unique identifier for each thread of execution
-and a single distinct value for all thread objects
-that do not represent a thread of execution ([thread.threads.class]).
-Each thread of execution has a <code>thread::id</code>
-that is not equal to the <code>thread::id</code>
-of other threads of execution
-and that is not equal to
-the <code>thread::id</code> of <code>std::thread</code> objects
-that do not represent threads of execution.
-<ins>The library may reuse the value of a <code>thread::id</code> of a
-terminated thread that can no longer be joined.</ins>
-</p>
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="789"></a>789. <tt>xor_combine_engine(result_type)</tt> should be explicit</h3>
-<p><b>Section:</b> 26.4.4.4 [rand.adapt.xor] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.adapt.xor">issues</a> in [rand.adapt.xor].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>xor_combine_engine(result_type)</tt> should be <tt>explicit</tt>. (Obvious oversight.)
-</p>
-
-<p><i>[
-Bellevue:
-]</i></p>
-
-
-<blockquote>
-Non-controversial. Bill is right, but Fermilab believes that this is
-easy to use badly and hard to use right, and so it should be removed
-entirely. Got into TR1 by well defined route, do we have permission to
-remove stuff? Should probably check with Jens, as it is believed he is
-the originator. Broad consensus that this is not a robust engine
-adapter.
-</blockquote>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Remove xor_combine_engine from synopsis of 26.4.2 [rand.synopsis].
-</p>
-<p>
-Remove 26.4.4.4 [rand.adapt.xor] <tt>xor_combine_engine</tt>.
-</p>
-
-
-
-
-
-<hr>
-<h3><a name="792"></a>792. <tt>piecewise_constant_distribution</tt> is undefined for a range with just one endpoint</h3>
-<p><b>Section:</b> 26.4.8.5.2 [rand.dist.samp.pconst] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> P.J. Plauger <b>Date:</b> 2008-02-09</p>
-<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#rand.dist.samp.pconst">active issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#rand.dist.samp.pconst">issues</a> in [rand.dist.samp.pconst].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<tt>piecewise_constant_distribution</tt> is undefined for a range with just one
-endpoint. (Probably should be the same as an empty range.)
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 26.4.8.5.2 [rand.dist.samp.pconst] paragraph 3b:
-</p>
-
-<blockquote>
-b) If <tt>firstB == lastB</tt> <ins>or the sequence <tt>w</tt> has the length zero</ins>,
-</blockquote>
-
-
-
-
-
-<hr>
-<h3><a name="798"></a>798. Refactoring of binders lead to interface breakage</h3>
-<p><b>Section:</b> D.8 [depr.lib.binders] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>
- <b>Submitter:</b> Daniel Krgler <b>Date:</b> 2008-02-14</p>
-<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#depr.lib.binders">issues</a> in [depr.lib.binders].</p>
-<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
-<p><b>Discussion:</b></p>
-<p>
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf">N2521</a>
-and its earlier predecessors have moved the old binders from
-[lib.binders] to D.8 [depr.lib.binders] thereby introducing some renaming
-of the template parameter names (<tt>Operation -&gt; Fn</tt>). During this
-renaming process the <em>protected</em> data member <tt>op</tt> was also renamed to
-<tt>fn</tt>, which seems as an unnecessary interface breakage to me - even if
-this user access point is probably rarely used.
-</p>
-
-
-<p><b>Proposed resolution:</b></p>
-<p>
-Change D.8.1 [depr.lib.binder.1st]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Fn&gt;
-class binder1st
- : public unary_function&lt;typename Fn::second_argument_type,
- typename Fn::result_type&gt; {
-protected:
- Fn <del>fn</del> <ins>op</ins>;
- typename Fn::first_argument_type value;
-public:
- binder1st(const Fn&amp; x,
- const typename Fn::first_argument_type&amp; y);
- typename Fn::result_type
- operator()(const typename Fn::second_argument_type&amp; x) const;
- typename Fn::result_type
- operator()(typename Fn::second_argument_type&amp; x) const;
-};
-</pre>
-
-<blockquote>
-<p>
--1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
-</p>
-<p>
--2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-<p>
-Change D.8.3 [depr.lib.binder.2nd]:
-</p>
-
-<blockquote>
-<pre>template &lt;class Fn&gt;
-class binder2nd
- : public unary_function&lt;typename Fn::first_argument_type,
- typename Fn::result_type&gt; {
-protected:
- Fn <del>fn</del> <ins>op</ins>;
- typename Fn::second_argument_type value;
-public:
- binder2nd(const Fn&amp; x,
- const typename Fn::second_argument_type&amp; y);
- typename Fn::result_type
- operator()(const typename Fn::first_argument_type&amp; x) const;
- typename Fn::result_type
- operator()(typename Fn::first_argument_type&amp; x) const;
-};
-</pre>
-
-<blockquote>
-<p>
--1- The constructor initializes <del><tt>fn</tt></del> <ins><tt>op</tt></ins> with <tt>x</tt> and <tt>value</tt> with <tt>y</tt>.
-</p>
-<p>
--2- <tt>operator()</tt> returns <tt><del>fn</del><ins>op</ins>(value,x)</tt>.
-</p>
-</blockquote>
-</blockquote>
-
-
-
-
-
-
-</body></html> \ No newline at end of file
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/PythonPoweredSmall.gif b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/PythonPoweredSmall.gif
deleted file mode 100644
index 268980706..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/PythonPoweredSmall.gif
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/acks.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/acks.html
deleted file mode 100644
index 6612a4a81..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/acks.html
+++ /dev/null
@@ -1,65 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Acknowledgments</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Acknowledgments</h1>
-
- <ol>
- <li>This library was partially written at <a href=
- "http://www.haifa.il.ibm.com/">IBM's Haifa Research
- Labs</a>.</li>
-
- <li>The library is based heavily on policy-based design and
- uses many useful techniques from [<a href=
- "references.html#alexandrescu01modern">alexandrescu01modern</a>].</li>
-
- <li>Two ideas are borrowed from the SGI-STL implementation
- [<a href="references.html#sgi_stl">sgi_stl</a>]:
-
- <ol>
- <li>The prime-based resize policies use a list of primes
- taken from the SGI-STL implementation.</li>
-
- <li>The red-black trees contain both a root node and a
- header node (containing metadata), connected in a way
- that forward and reverse iteration can be performed
- efficiently.</li>
- </ol>
- </li>
-
- <li>Some test utilities borrow ideas from [<a href=
- "references.html#boost_timer">boost_timer</a>].</li>
-
- <li>We would like to thank Scott Meyers for useful comments
- (without attributing to him any flaws in the design or
- implementation of the library).</li>
-
- <li>Much of the documentation is <a href=
- "http://www.python.org/"><img src="PythonPoweredSmall.gif"
- align="middle" width="55" height="22" alt="[Python Powered]"
- border="0" /></a> (especially through <a href=
- "http://home.gna.org/pychart/">PyChart</a>, <a href=
- "http://www.crummy.com/software/BeautifulSoup/">Beautiful
- Soup</a>, and <a href=
- "http://starship.python.net/crew/aaron_watters/kjbuckets/">kjbuckets</a>)
- and uses <a href="http://tidy.sourceforge.net/"><img src=
- "checked_by_tidy.gif" align="middle" width="55" height="45"
- alt="[HTML tidy]" border="0" /></a>. The CSS-driven menus are
- slightly modified from <a href=
- "http://www.brothercake.com/scripts/navmeister/page.php">Brothercake</a>
- (hopefully without introducing errors).</li>
- </ol>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.png
deleted file mode 100644
index 16cc6da87..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.svg b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.svg
deleted file mode 100644
index 02be62416..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_tag_cd.svg
+++ /dev/null
@@ -1,491 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Created with Inkscape (http://www.inkscape.org/) -->
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://web.resource.org/cc/"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- width="11in"
- height="8.5in"
- id="svg2"
- sodipodi:version="0.32"
- inkscape:version="0.43"
- version="1.0"
- sodipodi:docbase="/mnt/share/src/policy_based_data_structures/pb_ds_images"
- sodipodi:docname="assoc_tag_diagram_2.svg"
- inkscape:export-filename="/mnt/share/src/policy_based_data_structures/pb_ds_images/assoc_tag_diagram_2.png"
- inkscape:export-xdpi="90"
- inkscape:export-ydpi="90">
- <defs
- id="defs4">
- <marker
- inkscape:stockid="Arrow1Mstart"
- orient="auto"
- refY="0.0"
- refX="0.0"
- id="Arrow1Mstart"
- style="overflow:visible">
- <path
- id="path3311"
- d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
- style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none"
- transform="scale(0.4)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Sstart"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Sstart"
- style="overflow:visible">
- <path
- id="path3319"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(0.3,0,0,0.3,-1.5,0)" />
- </marker>
- <marker
- inkscape:stockid="Arrow1Sstart"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow1Sstart"
- style="overflow:visible">
- <path
- id="path3337"
- d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
- style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
- transform="scale(0.2,0.2)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Send"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Send"
- style="overflow:visible">
- <path
- id="path3316"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(-0.3,0,0,-0.3,1.5,0)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Mend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Mend"
- style="overflow:visible">
- <path
- id="path3322"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(-0.6,0,0,-0.6,3,0)" />
- </marker>
- <marker
- inkscape:stockid="Arrow1Lend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow1Lend"
- style="overflow:visible">
- <path
- id="path3346"
- d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
- style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
- transform="scale(-0.8,-0.8)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Lstart"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Lstart"
- style="overflow:visible">
- <path
- id="path3331"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(1.1,0,0,1.1,-5.5,0)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Lend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Lend"
- style="overflow:visible">
- <path
- id="path3328"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(-1.1,0,0,-1.1,5.5,0)" />
- </marker>
- </defs>
- <sodipodi:namedview
- id="base"
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1.0"
- inkscape:pageopacity="0.0"
- inkscape:pageshadow="2"
- inkscape:zoom="2"
- inkscape:cx="613.85775"
- inkscape:cy="310.05621"
- inkscape:document-units="in"
- inkscape:current-layer="layer1"
- showguides="true"
- inkscape:guide-bbox="true"
- inkscape:window-width="1278"
- inkscape:window-height="973"
- inkscape:window-x="0"
- inkscape:window-y="0"
- gridtolerance="0.125in"
- guidetolerance="0.125in">
- <sodipodi:guide
- orientation="horizontal"
- position="629"
- id="guide1307" />
- <sodipodi:guide
- orientation="horizontal"
- position="449"
- id="guide1309" />
- <sodipodi:guide
- orientation="horizontal"
- position="269"
- id="guide1311" />
- <sodipodi:guide
- orientation="vertical"
- position="496"
- id="guide1313" />
- <sodipodi:guide
- orientation="vertical"
- position="361"
- id="guide1315" />
- <sodipodi:guide
- orientation="vertical"
- position="226"
- id="guide1317" />
- <sodipodi:guide
- orientation="vertical"
- position="631"
- id="guide1319" />
- <sodipodi:guide
- orientation="vertical"
- position="766"
- id="guide1321" />
- <sodipodi:guide
- orientation="vertical"
- position="91"
- id="guide1345" />
- <sodipodi:guide
- orientation="vertical"
- position="901"
- id="guide1347" />
- <sodipodi:guide
- orientation="horizontal"
- position="539"
- id="guide3390" />
- <sodipodi:guide
- orientation="horizontal"
- position="359"
- id="guide3392" />
- <sodipodi:guide
- orientation="vertical"
- position="280.5"
- id="guide3324" />
- <sodipodi:guide
- orientation="vertical"
- position="172"
- id="guide3326" />
- <sodipodi:guide
- orientation="vertical"
- position="427"
- id="guide3328" />
- <sodipodi:guide
- orientation="vertical"
- position="711.5"
- id="guide3340" />
- <sodipodi:guide
- orientation="horizontal"
- position="179"
- id="guide1395" />
- </sodipodi:namedview>
- <metadata
- id="metadata7">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- <dc:creator>
- <cc:Agent>
- <dc:title>Benjamin Kosnik</dc:title>
- </cc:Agent>
- </dc:creator>
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <g
- inkscape:label="Layer 1"
- inkscape:groupmode="layer"
- id="layer1">
- <rect
- y="562.32806"
- x="237.8916"
- height="23.200001"
- width="80.769417"
- id="rect1495"
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.94391561;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.94391561;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect1497"
- width="80.769417"
- height="23.200001"
- x="132.8916"
- y="562.32806" />
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.94391561;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect1493"
- width="80.769417"
- height="23.200001"
- x="21.891602"
- y="562.32806" />
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect1425"
- width="141.64481"
- height="23.200001"
- x="209.57762"
- y="382.56177" />
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect3378"
- width="141.64481"
- height="23.200001"
- x="640.77765"
- y="382.56177" />
- <text
- xml:space="preserve"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans;stroke-miterlimit:4;stroke-dasharray:none"
- x="710.40002"
- y="397.09772"
- id="use1337"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1391"
- x="710.40003"
- y="397.09772">basic_hash_table_tag</tspan></text>
- <text
- xml:space="preserve"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="280"
- y="397.09772"
- id="text1339"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1385"
- x="280"
- y="397.09772">basic_tree_tag</tspan></text>
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect3418"
- width="141.64481"
- height="23.200001"
- x="101.57762"
- y="472.5618" />
- <rect
- y="472.5618"
- x="317.57761"
- height="23.200001"
- width="141.64481"
- id="rect3420"
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <text
- xml:space="preserve"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="171.20001"
- y="486.29773"
- id="text3394"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1387"
- x="171.20001"
- y="486.29773">tree_tag</tspan></text>
- <text
- sodipodi:linespacing="100%"
- id="text3400"
- y="486.29773"
- x="388.39999"
- style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
- xml:space="preserve"><tspan
- sodipodi:role="line"
- id="tspan1389"
- x="388.39999"
- y="486.29773">trie_tag</tspan></text>
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect3380"
- width="141.64481"
- height="23.200001"
- x="425.57764"
- y="292.56177" />
- <text
- xml:space="preserve"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="495.20001"
- y="307.09772"
- id="text1323"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1384"
- x="495.20001"
- y="307.09772">associative_container_tag</tspan></text>
- <path
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none"
- d="M 170.97058,472.5 L 170.97058,451 L 387.51871,450 L 387.51871,472.5"
- id="path2244" />
- <path
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="M 280.5,450.53297 L 280.5,410.62445"
- id="path3332" />
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect3422"
- width="141.64481"
- height="23.200001"
- x="533.57764"
- y="472.5618" />
- <rect
- y="472.5618"
- x="748.77765"
- height="23.200001"
- width="141.64481"
- id="rect3424"
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <text
- sodipodi:linespacing="100%"
- id="text3406"
- y="486.29773"
- x="601.20001"
- style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- xml:space="preserve"><tspan
- sodipodi:role="line"
- id="tspan1393"
- x="601.20001"
- y="486.29773">cc_hash_table_tag</tspan></text>
- <text
- xml:space="preserve"
- style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="818"
- y="486.29773"
- id="text3412"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1395"
- x="818"
- y="486.29773">gp_hash_table_tag</tspan></text>
- <path
- id="path3353"
- d="M 601.47058,472.5 L 601.47058,451 L 818.01871,450 L 818.01871,472.5"
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none" />
- <path
- id="path3355"
- d="M 711,450.53297 L 711,410.62445"
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <path
- id="path3344"
- d="M 281.18218,383.28102 L 281.18218,361.78102 L 711.79281,360.78102 L 711.79281,383.28102"
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none" />
- <rect
- y="383.1962"
- x="425.625"
- height="23.200001"
- width="141.64481"
- id="rect3376"
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <text
- sodipodi:linespacing="100%"
- id="use1329"
- y="397.73215"
- x="497.24741"
- style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
- xml:space="preserve"><tspan
- sodipodi:role="line"
- id="tspan1382"
- x="497.24741"
- y="397.73215">list_update_tag</tspan></text>
- <path
- id="path3347"
- d="M 497.79886,384.13056 L 497.79886,323.40547"
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <text
- xml:space="preserve"
- style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="61.152512"
- y="577.07874"
- id="text1423"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1418"
- x="61.152512"
- y="577.07874">rb_tree_tag</tspan></text>
- <text
- sodipodi:linespacing="100%"
- id="text1427"
- y="577.07874"
- x="277.95251"
- style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- xml:space="preserve"><tspan
- sodipodi:role="line"
- id="tspan1414"
- x="277.95252"
- y="577.07874">splay_tree_tag</tspan></text>
- <path
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none"
- d="M 61.42308,563.28102 L 61.42308,541.78102 L 277.97121,540.78102 L 277.97121,563.28102"
- id="path1431" />
- <path
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="M 170.9525,561.5357 L 170.9525,503.81235"
- id="path1433" />
- <rect
- y="562.17499"
- x="347.8916"
- height="23.200001"
- width="80.769417"
- id="rect1469"
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.94391561;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <text
- sodipodi:linespacing="100%"
- id="text1471"
- y="576.71094"
- x="388.80002"
- style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
- xml:space="preserve"><tspan
- sodipodi:role="line"
- id="tspan1412"
- x="388.80002"
- y="576.71094">pat_trie_tag</tspan></text>
- <path
- id="path1475"
- d="M 389.35146,563.10936 L 389.35146,502.38427"
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <text
- xml:space="preserve"
- style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="173.95251"
- y="577.07874"
- id="text1487"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1416"
- x="173.95251"
- y="577.07874">ov_tree_tag</tspan></text>
- </g>
-</svg>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_traits.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_traits.html
deleted file mode 100644
index 7814712c3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_container_traits.html
+++ /dev/null
@@ -1,170 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>container_traits Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>container_traits</tt> Interface</h1>
-
- <p>Traits of an associative-container based on its underlying
- data structure.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Cntnr59189" id="Cntnr59189"><b>class</b> Cntnr</a>
-</pre>
- </td>
-
- <td>
- <p>Container type.</p>
- </td>
-
- <td>-</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">Container Attributes</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="invalidation_guarantee3793555937" id=
-"invalidation_guarantee3793555937">invalidation_guarantee</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Invalidation guarantee.
-</pre>
- </td>
-
- <td>
- <p>Invalidation-guarantee type.</p>
-
- <p>This is either <a href=
- "basic_invalidation_guarantee.html"><span class=
- "c2"><tt>basic_invalidation_guarantee</tt></span></a>,
- <a href="point_invalidation_guarantee.html"><span class=
- "c2"><tt>point_invalidation_guarantee</tt></span></a>, or
- <a href="range_invalidation_guarantee.html"><span class=
- "c2"><tt>range_invalidation_guarantee</tt></span></a></p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="order_preserving1910229172" id=
-"order_preserving1910229172">order_preserving</a>
-</pre>
- </td>
-
- <td>
- <pre>
-True only if Cntnr objects guarantee storing keys by order.
-</pre>
- </td>
-
- <td>
- <p>Order-preserving indicator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="erase_can_throw153323856" id=
-"erase_can_throw153323856">erase_can_throw</a>
-</pre>
- </td>
-
- <td>
- <pre>
-True only if erasing a key can throw.
-</pre>
- </td>
-
- <td>
- <p>Erase-throw indicator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="reverse_iteration894617078" id=
-"reverse_iteration894617078">reverse_iteration</a>
-</pre>
- </td>
-
- <td>
- <pre>
-True only reverse iterators are supported.
-</pre>
- </td>
-
- <td>
- <p>Reverse iteration indicator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="split_join_can_throw3200477759" id=
-"split_join_can_throw3200477759">split_join_can_throw</a>
-</pre>
- </td>
-
- <td>
- <pre>
-True only if split or join operations can throw.
-</pre>
- </td>
-
- <td>
- <p>Split-join throw indicator.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_design.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_design.html
deleted file mode 100644
index 6c501e26b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_design.html
+++ /dev/null
@@ -1,46 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Associative Containers</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Associative-Container Design</h1>
-
- <ol>
- <li><a href="ds_gen.html">Data-Structure Genericity</a></li>
-
- <li class="c1">Genericity discusses generic manipulation of
- containers based on different underlying
- data structures.</li>
-
- <li class="c1">Genericity discusses generic manipulation of
- containers with different mapping semantics.</li>
-
- <li><a href="tree_based_containers.html">Tree-Based
- Containers</a> describes the design and policies of
- tree-based containers.</li>
-
- <li><a href="trie_based_containers.html">Trie-Based
- Containers</a> describes the design and policies of
- trie-based containers.</li>
-
- <li><a href="hash_based_containers.html">Hash-Based
- Containers</a> describes the design and policies of
- hash-based containers.</li>
-
- <li><a href="lu_based_containers.html">List-Based
- Containers</a> describes the design and policies of
- list-based containers with update policies.</li>
- </ol>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_examples.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_examples.html
deleted file mode 100644
index b64c74745..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_examples.html
+++ /dev/null
@@ -1,151 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Examples</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Associative-Container Examples</h1>
-
- <h2><a name="basic_usage" id="basic_usage">Basic Use</a></h2>
-
- <ol>
- <li>
- <a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_map.cc"><tt>basic_map.cc</tt></a>
- Basic use of "maps".</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_set.cc"><tt>basic_set.cc</tt></a>
- Basic use of "sets".</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/erase_if.cc"><tt>erase_if.cc</tt></a>
- Conditionally erasing values from a container object.</li>
- </ol>
-
- <h2><a name="generics" id="generics">Generics</a></h2>
-
- <ol>
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/assoc_container_traits.cc"><tt>assoc_container_traits.cc</tt></a>
- Using <a href=
- "assoc_container_traits.html"><tt>container_traits</tt></a> to query
- about underlying data structure behavior.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_find_neg.cc"><tt>hash_find_neg.cc</tt></a>
- A non-compiling example showing wrong use of finding keys in
- hash-based containers.</li>
- </ol>
-
- <h2><a name="hash_based" id="hash_based">Hash-Based
- Containers</a></h2>
-
-
- <h3><a name="resize_related" id="resize_related">Resize
- Related</a></h3>
-
-
- <ol>
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_initial_size.cc"><tt>hash_initial_size.cc</tt></a>
- Setting the initial size of a hash-based container
- object.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_resize_neg.cc"><tt>hash_resize_neg.cc</tt></a>
- A non-compiling example showing how not to resize a
- hash-based container object.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_resize.cc"><tt>hash_resize.cc</tt></a>
- Resizing the size of a hash-based container object.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_illegal_resize.cc"><tt>hash_illegal_resize.cc</tt></a>
- Showing an illegal resize of a hash-based container
- object.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_load_set_change.cc"><tt>hash_load_set_change.cc</tt></a>
- Changing the load factors of a hash-based container
- object.</li>
- </ol>
-
- <h3><a name="hash_related" id="hash_related">Hash-Function
- Related</a></h3>
-
-
- <ol>
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_mod.cc"><tt>hash_mod.cc</tt></a>
- Using a modulo range-hashing function for the case of an
- unknown skewed key distribution.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_shift_mask.cc"><tt>shift_mask.cc</tt></a>
- Writing a range-hashing functor for the case of a known
- skewed key distribution.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/store_hash.cc"><tt>store_hash.cc</tt></a>
- Storing the hash value along with each key.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/ranged_hash.cc"><tt>ranged_hash.cc</tt></a>
- Writing a ranged-hash functor.</li>
- </ol>
-
- <h2><a name="tree_like_based" id= "tree_like_based">Tree-Like Containers (Trees and
- Tries)</a></h2>
-
-
- <h3><a name="node_invariants" id=
- "node_invariants">Node-Invariants</a></h3>
-
-
- <ol>
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/tree_order_statistics.cc"><tt>tree_order_statistics.cc</tt></a>
- Using trees for order statistics.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/tree_intervals.cc"><tt>tree_intervals.cc</tt></a>
- Augmenting trees to support operations on line
- intervals.</li>
- </ol>
-
- <h3><a name="split_join" id="split_join">Split and
- Join</a></h3>
-
-
- <ol>
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/tree_join.cc"><tt>tree_join.cc</tt></a>
- Joining two tree-based container objects.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/trie_split.cc"><tt>trie_split.cc</tt></a>
- Splitting a PATRICIA trie container object.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/tree_order_statistics_join.cc"><tt>tree_order_statistics_join.cc</tt></a>
- Order statistics while joining two tree-based container
- objects.</li>
- </ol>
-
- <h2><a name="trie_based" id="trie_based">Trie-Based
- Containers</a></h2>
-
-
- <ol>
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/trie_dna.cc"><tt>trie_dna.cc</tt></a>
- Using a PATRICIA trie for DNA strings.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/trie_prefix_search.cc"><tt>trie_prefix_search.cc</tt></a>
- Using a PATRICIA trie for finding all entries whose key
- matches a given prefix.</li>
- </ol>
-
- <h2><a name="mmaps" id="mmaps">"Multimaps" and
- "Multisets".</a></h2>
- <ol>
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_multimap.cc"><tt>basic_multimap.cc</tt></a>
- Basic use of "multimaps".</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_multiset.cc"><tt>basic_multiset.cc</tt></a>
- Basic use of "multisets".</li>
- </ol>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_performance_tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_performance_tests.html
deleted file mode 100644
index 642f84809..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_performance_tests.html
+++ /dev/null
@@ -1,345 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Associative-Container Performance Tests</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1><a name="assoc" id="assoc">Associative-Container
- Performance Tests</a></h1>
-<h2><a name="settings" id="settings">Settings</a></h2>
-<p>This section describes performance tests and their results.
- In the following, <a href="#gcc"><u>g++</u></a>, <a href="#msvc"><u>msvc++</u></a>, and <a href="#local"><u>local</u></a> (the build used for generating this
- documentation) stand for three different builds:</p>
-<div id="gcc_settings_div">
-<div class="c1">
-<h3><a name="gcc" id="gcc"><u>g++</u></a></h3>
-<ul>
-<li>CPU speed - cpu MHz : 2660.644</li>
-<li>Memory - MemTotal: 484412 kB</li>
-<li>Platform -
- Linux-2.6.12-9-386-i686-with-debian-testing-unstable</li>
-<li>Compiler - g++ (GCC) 4.0.2 20050808 (prerelease)
- (Ubuntu 4.0.1-4ubuntu9) Copyright (C) 2005 Free Software
- Foundation, Inc. This is free software; see the source
- for copying conditions. There is NO warranty; not even
- for MERCHANTABILITY or FITNESS FOR A PARTICULAR
- PURPOSE.</li>
-</ul>
-</div>
-<div class="c2"></div>
-</div>
-<div id="msvc_settings_div">
-<div class="c1">
-<h3><a name="msvc" id="msvc"><u>msvc++</u></a></h3>
-<ul>
-<li>CPU speed - cpu MHz : 2660.554</li>
-<li>Memory - MemTotal: 484412 kB</li>
-<li>Platform - Windows XP Pro</li>
-<li>Compiler - Microsoft (R) 32-bit C/C++ Optimizing
- Compiler Version 13.10.3077 for 80x86 Copyright (C)
- Microsoft Corporation 1984-2002. All rights
- reserved.</li>
-</ul>
-</div>
-<div class="c2"></div>
-</div>
-<div id="local_settings_div"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h3><a name = "local"><u>local</u></a></h3><ul>
-<li>CPU speed - cpu MHz : 2250.000</li>
-<li>Memory - MemTotal: 2076248 kB</li>
-<li>Platform - Linux-2.6.16-1.2133_FC5-i686-with-redhat-5-Bordeaux</li>
-<li>Compiler - g++ (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
-Copyright (C) 2006 Free Software Foundation, Inc.
-This is free software; see the source for copying conditions. There is NO
-warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-</li>
-</ul>
-</div><div style = "width: 100%; height: 20px"></div></div>
-<h2><a name="assoc_tests" id="assoc_tests">Tests</a></h2>
-<h3><a name="hash_based" id="hash_based">Hash-Based
- Containers</a></h3>
-<ol>
-<li><a href="hash_text_find_find_timing_test.html">Hash-Based
- Text <tt>find</tt> Find Timing Test</a></li>
-<li><a href="hash_random_int_find_find_timing_test.html">Hash-Based
- Random-Integer <tt>find</tt> Find Timing Test</a></li>
-<li><a href="hash_random_int_subscript_find_timing_test.html">Hash-Based
- Random-Integer Subscript Find Timing Test</a></li>
-<li><a href="hash_random_int_subscript_insert_timing_test.html">Hash-Based
- Random-Integer Subscript Insert Timing Test</a></li>
-<li><a href="hash_zlob_random_int_find_find_timing_test.html">Hash-Based
- Skewed-Distribution Random-Integer <tt>find</tt> Find Timing
- Test</a></li>
-<li><a href="hash_random_int_erase_mem_usage_test.html">Hash-Based Erase
- Memory Use Test</a></li>
-</ol>
-<h3><a name="tree_like_based" id="tree_like_based">Tree-Like-Based Containers</a></h3>
-<ol>
-<li><a href="tree_text_insert_timing_test.html">Tree-Based
- and Trie-Based Text Insert Timing Test</a></li>
-<li><a href="tree_text_find_find_timing_test.html">Tree-Based
- and Trie-Based Text <tt>find</tt> Find Timing Test</a></li>
-<li><a href="tree_text_lor_find_find_timing_test.html">Tree-Based
- Locality-of-Reference Text <tt>find</tt> Find Timing
- Test</a></li>
-<li><a href="tree_random_int_find_find_timing_test.html">Tree-Based
- Random-Integer <tt>find</tt> Find Timing Test</a></li>
-<li><a href="tree_split_join_timing_test.html">Tree Split and
- Join Timing Test</a></li>
-<li><a href="tree_order_statistics_timing_test.html">Tree
- Order-Statistics Timing Test</a></li>
-</ol>
-<h3><a name="multimaps" id="multimaps">Multimaps</a></h3>
-<ol>
-<li><a href="multimap_text_find_timing_test_small.html">"Multimap"
- Text Find Timing Test with <u>Small</u> Average Secondary-Key
- to Primary-Key Ratio</a></li>
-<li><a href="multimap_text_find_timing_test_large.html">"Multimap"
- Text Find Timing Test with <u>Large</u> Average Secondary-Key
- to Primary-Key Ratio</a></li>
-<li><a href="multimap_text_insert_timing_test_small.html">"Multimap"
- Text Insert Timing Test with <u>Small</u> Average
- Secondary-Key to Primary-Key Ratio</a></li>
-<li><a href="multimap_text_insert_timing_test_large.html">"Multimap"
- Text Insert Timing Test with <u>Large</u> Average
- Secondary-Key to Primary-Key Ratio</a></li>
-<li><a href="multimap_text_insert_mem_usage_test_small.html">"Multimap"
- Text Insert Memory-Use Test with <u>Small</u> Average
- Secondary-Key to Primary-Key Ratio</a></li>
-<li><a href="multimap_text_insert_mem_usage_test_large.html">"Multimap"
- Text Insert Memory-Use Test with <u>Large</u> Average
- Secondary-Key to Primary-Key Ratio</a></li>
-</ol>
-<h2><a name="assoc_observations" id="assoc_observations">Observations</a></h2>
-<h3><a name="dss_family_choice" id="dss_family_choice">Underlying Data-Structure Families</a></h3>
-<p>In general, hash-based containers (see <a href="hash_based_containers.html">Design::Associative
- Containers::Hash-Based Containers</a>) have better timing
- performance than containers based on different underlying-data
- structures. The main reason to choose a tree-based (see
- <a href="tree_based_containers.html">Design::Associative
- Containers::Tree-Based Containers</a>) or trie-based container
- (see <a href="trie_based_containers.html">Design::Associative
- Containers::Trie-Based Containers</a>) is if a byproduct of the
- tree-like structure is required: either order-preservation, or
- the ability to utilize node invariants (see <a href="tree_based_containers.html#invariants">Design::Associative
- Containers::Tree-Based Containers::Node Invariants</a> and
- <a href="trie_based_containers.html#invariants">Design::Associative
- Containers::Trie-Based Containers::Node Invariants</a>). If
- memory-use is the major factor, an ordered-vector tree (see
- <a href="tree_based_containers.html">Design::Associative
- Containers::Tree-Based Containers</a>) gives optimal results
- (albeit with high modificiation costs), and a list-based
- container (see <a href="lu_based_containers.html">Design::Associative
- Containers::List-Based Containers</a>) gives reasonable
- results.</p>
-<h3><a name="hash_based_types" id="hash_based_types">Hash-Based
- Container Types</a></h3>
-<p>Hash-based containers are typically either collision
- chaining or probing (see <a href="hash_based_containers.html">Design::Associative
- Containers::Hash-Based Containers</a>). Collision-chaining
- containers are more flexible internally, and so offer better
- timing performance. Probing containers, if used for simple
- value-types, manage memory more efficiently (they perform far
- fewer allocation-related calls). In general, therefore, a
- collision-chaining table should be used. A probing container,
- conversely, might be used efficiently for operations such as
- eliminating duplicates in a sequence, or counting the number of
- occurrences within a sequence. Probing containers might be more
- useful also in multithreaded applications where each thread
- manipulates a hash-based container: in the STL, allocators have
- class-wise semantics (see [<a href="references.html#meyers96more">meyers96more</a>] - Item 10); a
- probing container might incur less contention in this case.</p>
-<h3><a name="hash_based_policies" id="hash_based_policies">Hash-Based Containers' Policies</a></h3>
-<p>In hash-based containers, the range-hashing scheme (see
- <a href="hash_based_containers.html#hash_policies">Design::Associative
- Containers::Hash-Based Containers::Hash Policies</a>) seems to
- affect performance more than other considerations. In most
- settings, a mask-based scheme works well (or can be made to
- work well). If the key-distribution can be estimated a-priori,
- a simple hash function can produce nearly uniform hash-value
- distribution. In many other cases (<i>e.g.</i>, text hashing,
- floating-point hashing), the hash function is powerful enough
- to generate hash values with good uniformity properties
- [<a href="references.html#knuth98sorting">knuth98sorting</a>];
- a modulo-based scheme, taking into account all bits of the hash
- value, appears to overlap the hash function in its effort.</p>
-<p>The range-hashing scheme determines many of the other
- policies (see <a href="hash_based_containers.html#policy_interaction">Design::Hash-Based
- Containers::Policy Interaction</a>). A mask-based scheme works
- well with an exponential-size policy (see <a href="hash_based_containers.html#resize_policies">Design::Associative
- Containers::Hash-Based Containers::Resize Policies</a>) ; for
- probing-based containers, it goes well with a linear-probe
- function (see <a href="hash_based_containers.html#hash_policies">Design::Associative
- Containers::Hash-Based Containers::Hash Policies</a>).</p>
-<p>An orthogonal consideration is the trigger policy (see
- <a href="hash_based_containers.html#resize_policies">Design::Associative
- Containers::Hash-Based Containers::Resize Policies</a>). This
- presents difficult tradeoffs. <i>E.g.</i>, different load
- factors in a load-check trigger policy yield a
- space/amortized-cost tradeoff.</p>
-<h3><a name="tree_like_based_types" id="tree_like_based_types">Tree-Like-Based Container
- Types</a></h3>
-<p>In general, there are several families of tree-based
- underlying data structures: balanced node-based trees
- (<i>e.g.</i>, red-black or AVL trees), high-probability
- balanced node-based trees (<i>e.g.</i>, random treaps or
- skip-lists), competitive node-based trees (<i>e.g.</i>, splay
- trees), vector-based "trees", and tries. (Additionally, there
- are disk-residing or network-residing trees, such as B-Trees
- and their numerous variants. An interface for this would have
- to deal with the execution model and ACID guarantees; this is
- out of the scope of this library.) Following are some
- observations on their application to different settings.</p>
-<p>Of the balanced node-based trees, this library includes a
- red-black tree (see <a href="tree_based_containers.html">Design::Associative
- Containers::Tree-Based Containers</a>), as does STL (in
- practice). This type of tree is the "workhorse" of tree-based
- containers: it offers both reasonable modification and
- reasonable lookup time. Unfortunately, this data structure
- stores a huge amount of metadata. Each node must contain,
- besides a value, three pointers and a boolean. This type might
- be avoided if space is at a premium [<a href="references.html#austern00noset">austern00noset</a>].</p>
-<p>High-probability balanced node-based trees suffer the
- drawbacks of deterministic balanced trees. Although they are
- fascinating data structures, preliminary tests with them showed
- their performance was worse than red-black trees. The library
- does not contain any such trees, therefore.</p>
-<p>Competitive node-based trees have two drawbacks. They are
- usually somewhat unbalanced, and they perform a large number of
- comparisons. Balanced trees perform one comparison per each
- node they encounter on a search path; a splay tree performs two
- comparisons. If the keys are complex objects, <i>e.g.</i>,
- <tt>std::string</tt>, this can increase the running time.
- Conversely, such trees do well when there is much locality of
- reference. It is difficult to determine in which case to prefer
- such trees over balanced trees. This library includes a splay
- tree (see <a href="tree_based_containers.html">Design::Associative
- Containers::Tree-Based Containers</a>).</p>
-<p>Ordered-vector trees (see <a href="tree_based_containers.html">Design::Associative
- Containers::Tree-Based Containers</a>) use very little space
- [<a href="references.html#austern00noset">austern00noset</a>].
- They do not have any other advantages (at least in this
- implementation).</p>
-<p>Large-fan-out PATRICIA tries (see <a href="trie_based_containers.html">Design::Associative
- Containers::Trie-Based Containers</a>) have excellent lookup
- performance, but they do so through maintaining, for each node,
- a miniature "hash-table". Their space efficiency is low, and
- their modification performance is bad. These tries might be
- used for semi-static settings, where order preservation is
- important. Alternatively, red-black trees cross-referenced with
- hash tables can be used. [<a href="references.html#okasaki98mereable">okasaki98mereable</a>]
- discusses small-fan-out PATRICIA tries for integers, but the
- cited results seem to indicate that the amortized cost of
- maintaining such trees is higher than that of balanced trees.
- Moderate-fan-out trees might be useful for sequences where each
- element has a limited number of choices, <i>e.g.</i>, DNA
- strings (see <a href="assoc_examples.html#trie_based">Examples::Associative
- Containers::Trie-Based Containers</a>).</p>
-<h3><a name="msc" id="msc">Mapping-Semantics
- Considerations</a></h3>
-<p>Different mapping semantics were discussed in <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Alternative to Multiple Equivalent Keys</a> and
- <a href="tutorial.html#assoc_ms">Tutorial::Associative
- Containers::Associative Containers Others than Maps</a>. We
- will focus here on the case where a keys can be composed into
- primary keys and secondary keys. (In the case where some keys
- are completely identical, it is trivial that one should use an
- associative container mapping values to size types.) In this
- case there are (at least) five possibilities:</p>
-<ol>
-<li>Use an associative container that allows equivalent-key
- values (such as <tt>std::multimap</tt>)</li>
-<li>Use a unique-key value associative container that maps
- each primary key to some complex associative container of
- secondary keys, say a tree-based or hash-based container (see
- <a href="tree_based_containers.html">Design::Associative
- Containers::Tree-Based Containers</a> and <a href="hash_based_containers.html">Design::Associative
- Containers::Hash-Based Containers</a>)</li>
-<li>Use a unique-key value associative container that maps
- each primary key to some simple associative container of
- secondary keys, say a list-based container (see <a href="lu_based_containers.html">Design::Associative
- Containers::List-Based Containers</a>)</li>
-<li>Use a unique-key value associative container that maps
- each primary key to some non-associative container
- (<i>e.g.</i>, <tt>std::vector</tt>)</li>
-<li>Use a unique-key value associative container that takes
- into account both primary and secondary keys.</li>
-</ol>
-<p>We do not think there is a simple answer for this (excluding
- option 1, which we think should be avoided in all cases).</p>
-<p>If the expected ratio of secondary keys to primary keys is
- small, then 3 and 4 seem reasonable. Both types of secondary
- containers are relatively lightweight (in terms of memory use
- and construction time), and so creating an entire container
- object for each primary key is not too expensive. Option 4
- might be preferable to option 3 if changing the secondary key
- of some primary key is frequent - one cannot modify an
- associative container's key, and the only possibility,
- therefore, is erasing the secondary key and inserting another
- one instead; a non-associative container, conversely, can
- support in-place modification. The actual cost of erasing a
- secondary key and inserting another one depends also on the
- allocator used for secondary associative-containers (The tests
- above used the standard allocator, but in practice one might
- choose to use, <i>e.g.</i>, [<a href="references.html#boost_pool">boost_pool</a>]). Option 2 is
- definitely an overkill in this case. Option 1 loses out either
- immediately (when there is one secondary key per primary key)
- or almost immediately after that. Option 5 has the same
- drawbacks as option 2, but it has the additional drawback that
- finding all values whose primary key is equivalent to some key,
- might be linear in the total number of values stored (for
- example, if using a hash-based container).</p>
-<p>If the expected ratio of secondary keys to primary keys is
- large, then the answer is more complicated. It depends on the
- distribution of secondary keys to primary keys, the
- distribution of accesses according to primary keys, and the
- types of operations most frequent.</p>
-<p>To be more precise, assume there are <i>m</i> primary keys,
- primary key <i>i</i> is mapped to <i>n<sub>i</sub></i>
- secondary keys, and each primary key is mapped, on average, to
- <i>n</i> secondary keys (<i>i.e.</i>,
- <i><b>E</b>(n<sub>i</sub>) = n</i>).</p>
-<p>Suppose one wants to find a specific pair of primary and
- secondary keys. Using 1 with a tree based container
- (<tt>std::multimap</tt>), the expected cost is
- <i><b>E</b>(&Theta;(log(m) + n<sub>i</sub>)) = &Theta;(log(m) +
- n)</i>; using 1 with a hash-based container
- (<tt>std::tr1::unordered_multimap</tt>), the expected cost is
- <i>&Theta;(n)</i>. Using 2 with a primary hash-based container
- and secondary hash-based containers, the expected cost is
- <i>O(1)</i>; using 2 with a primary tree-based container and
- secondary tree-based containers, the expected cost is (using
- the Jensen inequality [<a href="references.html#motwani95random">motwani95random</a>])
- <i><b>E</b>(O(log(m) + log(n<sub>i</sub>)) = O(log(m)) +
- <b>E</b>(O(log(n<sub>i</sub>)) = O(log(m)) + O(log(n))</i>,
- assuming that primary keys are accessed equiprobably. 3 and 4
- are similar to 1, but with lower constants. Using 5 with a
- hash-based container, the expected cost is <i>O(1)</i>; using 5
- with a tree based container, the cost is
- <i><b>E</b>(&Theta;(log(mn))) = &Theta;(log(m) +
- log(n))</i>.</p>
-<p>Suppose one needs the values whose primary key matches some
- given key. Using 1 with a hash-based container, the expected
- cost is <i>&Theta;(n)</i>, but the values will not be ordered
- by secondary keys (which may or may not be required); using 1
- with a tree-based container, the expected cost is
- <i>&Theta;(log(m) + n)</i>, but with high constants; again the
- values will not be ordered by secondary keys. 2, 3, and 4 are
- similar to 1, but typically with lower constants (and,
- additionally, if one uses a tree-based container for secondary
- keys, they will be ordered). Using 5 with a hash-based
- container, the cost is <i>&Theta;(mn)</i>.</p>
-<p>Suppose one wants to assign to a primary key all secondary
- keys assigned to a different primary key. Using 1 with a
- hash-based container, the expected cost is <i>&Theta;(n)</i>,
- but with very high constants; using 1 with a tree-based
- container, the cost is <i>&Theta;(nlog(mn))</i>. Using 2, 3,
- and 4, the expected cost is <i>&Theta;(n)</i>, but typically
- with far lower costs than 1. 5 is similar to 1.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_regression_tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_regression_tests.html
deleted file mode 100644
index 9b6b6b839..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_regression_tests.html
+++ /dev/null
@@ -1,93 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Associative-Container Regression Tests</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
-<base href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/regression/">
- </head>
-
-<body>
- <div id="page">
- <h1>Associative-Container Regression Tests</h1>
-
- <h2><a name="assoc_desc" id="assoc_desc">Description</a></h2>
-
- <p>The library contains a single comprehensive regression test.
- For a given container type in <tt>pb_ds</tt>, the test creates
- an object of the container type and an object of the
- corresponding STL type (<i>e.g.</i>, <tt>std::set</tt>). It
- then performs a random sequence of methods with random
- arguments (<i>e.g.</i>, inserts, erases, and so forth) on both
- objects. At each operation, the test checks the return value of
- the method, and optionally both compares <tt>pb_ds</tt>'s
- object with the STL's object as well as performing other
- consistency checks on <tt>pb_ds</tt>'s object (<i>e.g.</i>,
- order preservation, when applicable, or node invariants, when
- applicable).</p>
-
- <p>Additionally, the test integrally checks exception safety
- and resource leaks. This is done as follows. A special
- allocator type, written for the purpose of the test, both
- randomly throws an exceptions when allocations are performed,
- and tracks allocations and de-allocations. The exceptions thrown
- at allocations simulate memory-allocation failures; the
- tracking mechanism checks for memory-related bugs (<i>e.g.</i>,
- resource leaks and multiple de-allocations). Both
- <tt>pb_ds</tt>'s containers and the containers' value-types are
- configured to use this allocator.</p>
-
- <p>Due to compiler constraints, the test is split into the
- several sources, each checking only some containers.</p>
-
- <h2><a name="assoc_tests" id="assoc_tests">Tests</a></h2>
-
- <h3><a name="assoc_tests_set" id="assoc_tests_set">"Set"
- Tests</a></h3>
-
- <p>The following check all "set" types:</p>
-
- <ol>
- <li><a href=
- "hash_no_data_map_rand.cc"><tt>hash_no_data_map_rand.cc</tt></a>
- checks all hash-based "set" types.</li>
-
- <li><a href=
- "list_update_no_data_map_rand.cc"><tt>list_update_no_data_map_rand.cc</tt></a>
- checks all list-based "set" types.</li>
-
- <li><a href=
- "tree_no_data_map_rand.cc"><tt>tree_no_data_map_rand.cc</tt></a>
- checks all tree-based "set" types.</li>
-
- <li><a href=
- "trie_no_data_map_rand.cc"><tt>trie_no_data_map_rand.cc</tt></a>
- checks all PATRICIA-trie-based "set" types.</li>
- </ol>
-
- <h3><a name="assoc_tests_map" id="assoc_tests_map">"Map"
- Tests</a></h3>
-
- <p>The following check all "map" types:</p>
-
- <ol>
- <li><a href= "hash_data_map_rand.cc"><tt>hash_data_map_rand.cc</tt></a>
- checks all hash-based "map" types.</li>
-
- <li><a href= "list_update_data_map_rand.cc"><tt>list_update_data_map_rand.cc</tt></a>
- checks all list-based "map" types.</li>
-
- <li><a href= "tree_data_map_rand.cc"><tt>tree_data_map_rand.cc</tt></a>
- checks all tree-based "map" types.</li>
-
- <li><a href= "trie_data_map_rand.cc"><tt>trie_data_map_rand.cc</tt></a>
- checks all PATRICIA-trie-based "map" types.</li>
- </ol>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_tests.html
deleted file mode 100644
index 6e4474945..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/assoc_tests.html
+++ /dev/null
@@ -1,24 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Associative-Container Tests</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Associative-Container Tests</h1>
-
- <p><a href="assoc_regression_tests.html">Associative-Container
- Regression Tests</a> describes the regression tests; <a href=
- "assoc_performance_tests.html">Associative-Container
- Performance Tests</a> describes the performance tests.</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/associative_container_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/associative_container_tag.html
deleted file mode 100644
index ceb91cdc7..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/associative_container_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>associative_container_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>associative_container_tag</tt> Interface</h1>
-
- <p>Basic associative-container data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="container_tag.html"><span class=
-"c2"><tt>container_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/balls_and_bins.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/balls_and_bins.png
deleted file mode 100644
index 529c3ae41..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/balls_and_bins.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_table.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_table.html
deleted file mode 100644
index 668e681d8..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_table.html
+++ /dev/null
@@ -1,436 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>basic_hash_table Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>basic_hash_table</tt> Interface</h1>
-
- <p>An abstract basic hash-based associative container.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Key2501" id="Key2501"><b>typename</b> Key</a>
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a>
-</pre>
- </td>
-
- <td>
- <p>Mapped type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Hash_Fn1515835" id=
-"Hash_Fn1515835"><b>class</b> Hash_Fn</a>
-</pre>
- </td>
-
- <td>
- <p>Hash functor.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Eq_Fn60085" id="Eq_Fn60085"><b>class</b> Eq_Fn</a>
-</pre>
- </td>
-
- <td>
- <p>Equivalence functor.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Resize_Policy566860465" id=
-"Resize_Policy566860465"><b>class</b> Resize_Policy</a>
-</pre>
- </td>
-
- <td>
- <p>Resize policy.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Store_Hash218262104" id=
-"Store_Hash218262104"><b>bool</b> Store_Hash</a>
-</pre>
- </td>
-
- <td>
- <p>Indicates whether the hash value will be stored along
- with each key.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Tag278938" id="Tag278938"><b>class</b> Tag</a>
-</pre>
- </td>
-
- <td>
- <p>Mapped-structure tag.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator</a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>-</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#Resize_Policy566860465"><tt>Resize_Policy</tt></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="container_base.html"><span class=
-"c2"><tt>container_base</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Types and
- Constants</a></h2>
-
- <h3><a name="link4" id="link4">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="hash_fn2015995" id="hash_fn2015995">hash_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Hash_Fn1515835"><tt>Hash_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Hash functor type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="eq_fn80245" id="eq_fn80245">eq_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Eq_Fn60085"><tt>Eq_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Equivalence functor type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="resize_policy4084493169" id=
-"resize_policy4084493169">resize_policy</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Resize_Policy566860465"><tt>Resize_Policy</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Resize policy type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="store_hash280766104" id=
-"store_hash280766104">store_hash</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Store_Hash218262104"><tt>Store_Hash</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Indicates whether a hash value is stored with each
- entry.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Public Methods</a></h2>
-
- <h3><a name="link6" id="link6">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b>
- ~basic_hash_table
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Policy Access Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#hash_fn2015995"><tt>hash_fn</tt></a> &amp;
- get_hash_fn
- ()
-</pre>
- </td>
-
- <td>
- <p>Access to the <a href=
- "#hash_fn2015995"><tt>hash_fn</tt></a> object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>const</b> <a href="#hash_fn2015995"><tt>hash_fn</tt></a> &amp;
- get_hash_fn
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Const access to the <a href=
- "#hash_fn2015995"><tt>hash_fn</tt></a> object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#eq_fn80245"><tt>eq_fn</tt></a> &amp;
- get_eq_fn
- ()
-</pre>
- </td>
-
- <td>
- <p>Access to the <a href="#eq_fn80245"><tt>eq_fn</tt></a>
- object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>const</b> <a href="#eq_fn80245"><tt>eq_fn</tt></a> &amp;
- get_eq_fn
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Const access to the <a href=
- "#eq_fn80245"><tt>eq_fn</tt></a> object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#resize_policy4084493169"><tt>resize_policy</tt></a> &amp;
- get_resize_policy
- ()
-</pre>
- </td>
-
- <td>
- <p>Access to the <a href=
- "#resize_policy4084493169"><tt>resize_policy</tt></a>
- object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>const</b> <a href=
-"#resize_policy4084493169"><tt>resize_policy</tt></a> &amp;
- get_resize_policy
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Const access to the <a href=
- "#resize_policy4084493169"><tt>resize_policy</tt></a>
- object.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link8" id="link8">Private Methods</a></h2>
-
- <h3><a name="link9" id="link9">Resize Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <b>void</b>
- do_resize
- (size_type new_size)
-</pre>
- </td>
-
- <td>
- <p>Resizes the container object to <span class=
- "c1"><tt>new_size</tt></span>.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_tag.html
deleted file mode 100644
index 9dc5e6d86..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_hash_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>basic_hash_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>basic_hash_tag</tt> Interface</h1>
-
- <p>Basic hash data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="associative_container_tag.html"><span class=
-"c2"><tt>associative_container_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_invalidation_guarantee.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_invalidation_guarantee.html
deleted file mode 100644
index d4a0df23f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_invalidation_guarantee.html
+++ /dev/null
@@ -1,26 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>basic_invalidation_guarantee Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>basic_invalidation_guarantee</tt> Interface</h1>
-
- <p>Signifies a basic invalidation guarantee that any iterator,
- pointer, or reference to a container object's mapped value type
- is valid as long as the container is not modified.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree.html
deleted file mode 100644
index 3811707fa..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree.html
+++ /dev/null
@@ -1,660 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>basic_tree Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>basic_tree</tt> Interface</h1>
-
- <p>An abstract basic tree-like-based associative container.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Key2501" id="Key2501"><b>typename</b> Key</a>
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a>
-</pre>
- </td>
-
- <td>
- <p>Mapped type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Tag278938" id="Tag278938"><b>class</b> Tag</a>
-</pre>
- </td>
-
- <td>
- <p>Mapped-structure tag.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Node_Update841554648" id=
-"Node_Update841554648"><b>class</b> Node_Update</a>
-</pre>
- </td>
-
- <td>
- <p>Node updater.</p>
-
- <p>Restores node-invariants when invalidated.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Policy_Tl42017403" id=
-"Policy_Tl42017403"><b>class</b> Policy_Tl</a>
-</pre>
- </td>
-
- <td>
- <p>Policy typelist.</p>
-
- <p>Contains subclasses' policies.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator</a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>-</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#Node_Update841554648"><tt>Node_Update</tt></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="container_base.html"><span class=
-"c2"><tt>container_base</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Types and
- Constants</a></h2>
-
- <h3><a name="link4" id="link4">Key-Type Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_key_reference3185471705" id=
-"const_key_reference3185471705">const_key_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href="container_base.html"><span class=
-"c2"><tt>container_base</tt></span></a>::const_key_reference
-</pre>
- </td>
-
- <td>
- <p>Const key reference type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link5" id="link5">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="node_update2404554648" id=
-"node_update2404554648">node_update</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Node_Update841554648"><tt>Node_Update</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Node updater type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link6" id="link6">Iterator Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_iterator98626788" id=
-"const_iterator98626788">const_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href="container_base.html"><span class=
-"c2"><tt>container_base</tt></span></a>::const_iterator
-</pre>
- </td>
-
- <td>
- <p>Const range-type iterator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="iterator10418194" id="iterator10418194">iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href="container_base.html"><span class=
-"c2"><tt>container_base</tt></span></a>::iterator
-</pre>
- </td>
-
- <td>
- <p>Range-type iterator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_reverse_iterator4151293083" id=
-"const_reverse_iterator4151293083">const_reverse_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Const reverse range-type iterator.
-</pre>
- </td>
-
- <td>
- <p>Const reverse range-type <a href=
- "#iterator10418194"><tt>iterator</tt></a>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="reverse_iterator1896910345" id=
-"reverse_iterator1896910345">reverse_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Reverse range-type iterator.<br />
-If <a href="#Mapped318655"><tt>Mapped</tt></a> is <a href=
-"null_mapped_type.html"><span class=
-"c2"><tt>null_mapped_type</tt></span></a>, then this is synonymous to <a href="#const_reverse_iterator4151293083"><tt>const_reverse_iterator</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Reverse range-type <a href=
- "#iterator10418194"><tt>iterator</tt></a>.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link7" id="link7">Public Methods</a></h2>
-
- <h3><a name="link8" id="link8">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b>
- ~basic_tree
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link9" id="link9">Policy Access Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#node_update2404554648"><tt>node_update</tt></a> &amp;
- get_node_update
- ()
-</pre>
- </td>
-
- <td>
- <p>Access to the <a href=
- "#node_update2404554648"><tt>node_update</tt></a>
- object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>const</b> <a href=
-"#node_update2404554648"><tt>node_update</tt></a> &amp;
- get_node_update
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Const access to the <a href=
- "#node_update2404554648"><tt>node_update</tt></a>
- object.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link10" id="link10">Find Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#iterator10418194"><tt>iterator</tt></a>
- lower_bound
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key)
-</pre>
- </td>
-
- <td>
- <p>Returns an <a href=
- "#iterator10418194"><tt>iterator</tt></a> corresponding
- to the entry whose key is the smallest one at least as
- large as <span class="c1"><tt>r_key</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#const_iterator98626788"><tt>const_iterator</tt></a>
- lower_bound
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a <tt><b>const</b></tt> <a href=
- "#iterator10418194"><tt>iterator</tt></a> corresponding
- to the entry whose key is the smallest one at least as
- large as <span class="c1"><tt>r_key</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#iterator10418194"><tt>iterator</tt></a>
- upper_bound
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key)
-</pre>
- </td>
-
- <td>
- <p>Returns an <a href=
- "#iterator10418194"><tt>iterator</tt></a> corresponding
- to the entry whose key is the smallest one larger than
- <span class="c1"><tt>r_key</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#const_iterator98626788"><tt>const_iterator</tt></a>
- upper_bound
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a>
- corresponding to the entry whose key is the smallest one
- larger than <span class="c1"><tt>r_key</tt></span>.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link11" id="link11">Erase Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#iterator10418194"><tt>iterator</tt></a>
- erase
- (<a href="#iterator10418194"><tt>iterator</tt></a> it)
-</pre>
- </td>
-
- <td>
- <p>Erases the value_type corresponding to the <a href=
- "#iterator10418194"><tt>iterator</tt></a> <span class=
- "c1"><tt>it</tt></span>. Returns the <a href=
- "#iterator10418194"><tt>iterator</tt></a> corresponding
- to the next value_type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#reverse_iterator1896910345"><tt>reverse_iterator</tt></a>
- erase
- (<a href=
-"#reverse_iterator1896910345"><tt>reverse_iterator</tt></a> it)
-</pre>
- </td>
-
- <td>
- <p>Erases the value_type corresponding to the <a href=
- "#reverse_iterator1896910345"><tt>reverse_iterator</tt></a>
- <span class="c1"><tt>it</tt></span>. Returns the <a href=
- "#reverse_iterator1896910345"><tt>reverse_iterator</tt></a>
- corresponding to the previous value_type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link12" id="link12">Iteration Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#reverse_iterator1896910345"><tt>reverse_iterator</tt></a>
- rbegin
- ()
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#reverse_iterator1896910345"><tt>reverse_iterator</tt></a>
- corresponding to the last value_type in the
- container.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href=
-"#const_reverse_iterator4151293083"><tt>const_reverse_iterator</tt></a>
- rbegin
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_reverse_iterator4151293083"><tt>const_reverse_iterator</tt></a>
- corresponding to the last value_type in the
- container.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#reverse_iterator1896910345"><tt>reverse_iterator</tt></a>
- rend
- ()
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#reverse_iterator1896910345"><tt>reverse_iterator</tt></a>
- corresponding to the just-before-first value_type in the
- container.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href=
-"#const_reverse_iterator4151293083"><tt>const_reverse_iterator</tt></a>
- rend
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_reverse_iterator4151293083"><tt>const_reverse_iterator</tt></a>
- corresponding to the just-before-first value_type in the
- container.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link13" id="link13">Split and join
- Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- join
- (<span class=
-"c2"><tt>basic_tree</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Joins two trees. When this function returns,
- <span class="c1"><tt>other</tt></span> will be
- empty.</p>
-
- <p>When calling this method, <span class=
- "c1"><tt>other</tt></span>'s keys must be all larger or
- all smaller than this object's keys, and <span class=
- "c1"><tt>other</tt></span>'s policies must be
- equivalent to this object's policies.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- split
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key,
- <span class=
-"c2"><tt>basic_tree</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Splits into two trees. When this function returns,
- <span class="c1"><tt>other</tt></span> will contain
- only keys larger than <span class=
- "c1"><tt>r_key</tt></span>.</p>
-
- <p>When calling this method, <span class=
- "c1"><tt>other</tt></span>'s policies must be
- equivalent to this object's policies.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_assoc_container_const_node_iterator.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_assoc_container_const_node_iterator.html
deleted file mode 100644
index 5647f551e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_assoc_container_const_node_iterator.html
+++ /dev/null
@@ -1,383 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>tree::const_node_iterator
- Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt><span class=
- "c2"><tt>tree</tt></span>::const_node_iterator</tt>
- Interface</h1>
-
- <p>Const node iterator.</p>
-
- <p>This is an &amp;qout;iterator to an iterator&amp;qout; - it
- iterates over nodes, and de-referencing it returns one of the
- tree's iterators</p>
-
- <h2><a name="link1" id="link1">Public Types and
- Constants</a></h2>
-
- <h3><a name="link2" id="link2">Iterator Definitions</a></h3>
-
- <table class="c2" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="iterator_category2821876439" id=
-"iterator_category2821876439">iterator_category</a>
-</pre>
- </td>
-
- <td>
- <pre>
-trivial_iterator_tag
-</pre>
- </td>
-
- <td>
- <p>Category.</p>
-
- <p>This tag identifies that the iterator has none of the
- STL's iterators' movement abilities.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="difference_type868028452" id=
-"difference_type868028452">difference_type</a>
-</pre>
- </td>
-
- <td>
- <pre class="c1">
-void
-</pre>
- </td>
-
- <td>
- <p>Difference type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link3" id="link3">Value-Type Definitions</a></h3>
-
- <p>Note that a node iterator's value type is actually a tree
- iterator.</p>
-
- <table class="c2" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="value_type279018186" id=
-"value_type279018186">value_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"container_base.html#const_iterator98626788"><span class="c2"><tt>container_base</tt></span>::const_iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Iterator's value type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="reference54418471" id="reference54418471">reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"container_base.html#const_iterator98626788"><span class="c2"><tt>container_base</tt></span>::const_iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Iterator's reference type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_reference495461441" id=
-"const_reference495461441">const_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"container_base.html#const_iterator98626788"><span class="c2"><tt>container_base</tt></span>::const_iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Iterator's const <a href=
- "#reference54418471"><tt>reference</tt></a> type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">Metadata Definitions</a></h3>
-
- <p>These are only defined if <a href=
- "basic_tree.html#Node_Update841554648"><span class="c2">
- <tt>basic_tree</tt></span>::Node_Update</a>
- is not <a href="null_tree_node_update.html"><span class=
- "c2"><tt>null_tree_node_update</tt></span></a></p>
-
- <table class="c2" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_type2849297114" id=
-"metadata_type2849297114">metadata_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<tt><b>typename</b></tt> <a href=
-"basic_tree.html#Node_Update841554648"><span class="c2"><tt>basic_tree</tt></span>::Node_Update</a><tt>::metadata_type</tt>
-</pre>
- </td>
-
- <td>
- <p>Metadata type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_metadata_reference1108857465" id=
-"const_metadata_reference1108857465">const_metadata_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> Allocator::<b>template</b> rebind&lt;
- <a href=
-"#metadata_type2849297114"><tt>metadata_type</tt></a>&gt;::other::<a href="#const_reference495461441"><tt>const_reference</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Const metadata <a href=
- "#reference54418471"><tt>reference</tt></a> type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Public Methods</a></h2>
-
- <h3><a name="link6" id="link6">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c2" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b>
- const_node_iterator
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Access Methods</a></h3>
-
- <table class="c2" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href=
-"#const_reference495461441"><tt>const_reference</tt></a>
- <b>operator</b>*
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Access.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link8" id="link8">Metadata Access Methods</a></h3>
-
- <p>These are only defined if <a href=
- "basic_tree.html#Node_Update841554648"><span class="c2">
- <tt>basic_tree</tt></span>::Node_Update</a>
- is not <a href="null_tree_node_update.html"><span class=
- "c2"><tt>null_tree_node_update</tt></span></a></p>
-
- <table class="c2" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href=
-"#const_metadata_reference1108857465"><tt>const_metadata_reference</tt></a>
- get_metadata
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Metadata access.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link9" id="link9">Movement Methods</a></h3>
-
- <table class="c2" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <span class="c2"><tt>const_node_iterator</tt></span>
- get_l_child
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the const node iterator associated with the
- left node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <span class="c2"><tt>const_node_iterator</tt></span>
- get_r_child
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the const node iterator associated with the
- right node.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link10" id="link10">Comparison Methods</a></h3>
-
- <table class="c2" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- <b>operator</b>==
- (<b>const</b> <span class=
-"c2"><tt>const_node_iterator</tt></span> &amp;other) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Compares to a different iterator object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- <b>operator</b>!=
- (<b>const</b> <span class=
-"c2"><tt>const_node_iterator</tt></span> &amp;other) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Compares (negatively) to a different iterator
- object.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_tag.html
deleted file mode 100644
index 8eca2a818..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/basic_tree_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>basic_tree_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>basic_tree_tag</tt> Interface</h1>
-
- <p>Basic tree-like data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="associative_container_tag.html"><span class=
-"c2"><tt>associative_container_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_heap_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_heap_tag.html
deleted file mode 100644
index 47873b1cf..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_heap_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>binary_heap_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>binary_heap_tag</tt> Interface</h1>
-
- <p>Binary-heap (array-based) data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="priority_queue_tag.html"><span class=
-"c2"><tt>priority_queue_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_gcc.png
deleted file mode 100644
index 07f0953a6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_local.png
deleted file mode 100644
index 76e02f134..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_msvc.png
deleted file mode 100644
index b8a3b2371..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binary_priority_queue_random_int_push_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binomial_heap_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binomial_heap_tag.html
deleted file mode 100644
index fde6a913b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/binomial_heap_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>binomial_heap_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>binomial_heap_tag</tt> Interface</h1>
-
- <p>Binomial-heap data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="priority_queue_tag.html"><span class=
-"c2"><tt>priority_queue_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html
deleted file mode 100644
index a6b512b0d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_max_collision_check_resize_trigger.html
+++ /dev/null
@@ -1,532 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>cc_hash_max_collision_check_resize_trigger
- Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>cc_hash_max_collision_check_resize_trigger</tt>
- Interface</h1>
-
- <p>A resize trigger policy based on collision checks. It keeps
- the simulated load factor lower than some given load
- factor.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="External_Load_Access1313998607" id=
-"External_Load_Access1313998607"><b>bool</b> External_Load_Access </a>
-</pre>
- </td>
-
- <td>
- <p>Specifies whether the load factor can be accessed
- externally. The two options have different trade-offs in
- terms of flexibility, genericity, and encapsulation.</p>
- </td>
-
- <td><tt><b>false</b></tt></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Size_Type42920436" id=
-"Size_Type42920436"><b>typename</b> Size_Type </a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
-
- <td>size_t</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Size_Type42920436"><tt>Size_Type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="external_load_access3976598639" id=
-"external_load_access3976598639">external_load_access</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"#External_Load_Access1313998607"><tt>External_Load_Access</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Indicates whether loads can be accessed externally</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link4" id="link4">Public Methods</a></h2>
-
- <h3><a name="link5" id="link5">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- cc_hash_max_collision_check_resize_trigger
- (float load = 0.5)
-</pre>
- </td>
-
- <td>
- <p>Default constructor, or constructor taking
- <span class="c1"><tt>load</tt></span>, a load factor
- which it will attempt to maintain.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class=
-"c2"><tt>cc_hash_max_collision_check_resize_trigger</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link6" id="link6">Load Access Methods</a></h3>
-
- <p>These methods are only available if the external access
- parameter is set.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> float
- get_load
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the current load.</p>
-
- <p>Calling this method will not compile when <a href=
- "#External_Load_Access1313998607"><tt>External_Load_Access</tt></a>
- == <tt><b>false</b></tt>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- set_load
- (float load)
-</pre>
- </td>
-
- <td>
- <p>Sets the <span class="c1"><tt>load</tt></span>; does
- not resize the container.</p>
-
- <p>It is the responsibility of the user to pass an
- appropriate <span class="c1"><tt>load</tt></span> to this
- function. Calling this method will not compile when
- <a href=
- "#External_Load_Access1313998607"><tt>External_Load_Access</tt></a>
- == <tt><b>false</b></tt>.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link7" id="link7">Protected Methods</a></h2>
-
- <h3><a name="link8" id="link8">Insert Search
- Notifications.</a></h3>
-
- <p>Notifications called during an insert operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link9" id="link9">Find Search
- Notifications.</a></h3>
-
- <p>Notifications called during a find operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link10" id="link10">Erase Search
- Notifications.</a></h3>
-
- <p>Notifications called during an insert operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link11" id="link11">Content Change
- Notifications</a></h3>
-
- <p>Notifications called when the content of the table changes
- in a way that can affect the resize policy.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_inserted
- (<a href="#size_type55424436"><tt>size_type</tt></a> num_entries)
-</pre>
- </td>
-
- <td>
- <p>Notifies an element was inserted.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erased
- (<a href="#size_type55424436"><tt>size_type</tt></a> num_entries)
-</pre>
- </td>
-
- <td>
- <p>Notifies an element was erased.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_cleared
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was cleared.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link12" id="link12">Size Change
- Notifications</a></h3>
-
- <p>Notifications called when the table changes size.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_resized
- (<a href="#size_type55424436"><tt>size_type</tt></a> new_size)
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was resized as a result of this
- object's signifying that a resize is needed.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_externally_resized
- (<a href="#size_type55424436"><tt>size_type</tt></a> new_size)
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was resized externally.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link13" id="link13">Queries</a></h3>
-
- <p>Called to query whether/how to resize.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- is_resize_needed
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Queries whether a resize is needed.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- is_grow_needed
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> size, <a href=
-"#size_type55424436"><tt>size_type</tt></a> num_entries) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Queries whether a grow is needed.</p>
-
- <p>This method is called only if this object indicated is
- needed.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_gcc.png
deleted file mode 100644
index 85b9eca4f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_local.png
deleted file mode 100644
index 4f578c65b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_msvc.png
deleted file mode 100644
index d1234aa11..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_find_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_gcc.png
deleted file mode 100644
index 1db2cc0c6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_local.png
deleted file mode 100644
index ca4db96f4..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_msvc.png
deleted file mode 100644
index 0b51d9432..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_find_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_gcc.png
deleted file mode 100644
index 6e4940381..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_local.png
deleted file mode 100644
index 48fcf76c0..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_msvc.png
deleted file mode 100644
index 39c96ad8d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_random_int_subscript_timing_test_insert_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_table.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_table.html
deleted file mode 100644
index 0557732a5..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_table.html
+++ /dev/null
@@ -1,724 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>cc_hash_table Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>cc_hash_table</tt> Interface</h1>
-
- <p>A concrete collision-chaining hash-based associative
- container.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Key2501" id="Key2501"><b>typename</b> Key</a>
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a>
-</pre>
- </td>
-
- <td>
- <p>Mapped type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Hash_Fn1515835" id=
-"Hash_Fn1515835"><b>class</b> Hash_Fn </a>
-</pre>
- </td>
-
- <td>
- <p>Hash functor.</p>
- </td>
-
- <td>
- <pre>
-__gnu_cxx::hash&lt;<a href="#Key2501"><tt>Key</tt></a>&gt;
-</pre>if using gcc;
- <pre>
-stdext::hash_value&lt;<a href="#Key2501"><tt>Key</tt></a>&gt;
-</pre>if using Visual C++ .net
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Eq_Fn60085" id="Eq_Fn60085"><b>class</b> Eq_Fn </a>
-</pre>
- </td>
-
- <td>
- <p>Equivalence functor.</p>
- </td>
-
- <td>
- <pre>
-std::equal_to&lt;<a href="#Key2501"><tt>Key</tt></a>&gt;
-</pre>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Comb_Hash_Fn320611039" id=
-"Comb_Hash_Fn320611039"><b>class</b> Comb_Hash_Fn </a>
-</pre>
- </td>
-
- <td>
- <p>Combining hash functor.</p>
-
- <p>If <a href="#Hash_Fn1515835"><tt>Hash_Fn</tt></a> is
- not <a href="null_hash_fn.html"><span class=
- "c2"><tt>null_hash_fn</tt></span></a>, then this is the
- ranged-hash functor; otherwise, this is the range-hashing
- functor.</p>
-
- <p>(See <a href=
- "hash_based_containers.html#hash_policies">Design::Hash-Based
- Containers::Hash Policies</a>.)</p>
- </td>
-
- <td>
- <pre>
-<a href="direct_mask_range_hashing.html"><span class=
-"c2"><tt>direct_mask_range_hashing</tt></span></a>
-</pre>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Resize_Policy566860465" id=
-"Resize_Policy566860465"><b>class</b> Resize_Policy </a>
-</pre>
- </td>
-
- <td>
- <p>Resize policy.</p>
- </td>
-
- <td>
- If <tt><a href=
- "#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a></tt>
- is <tt><a href=
- "direct_mask_range_hashing.html"><span class=
- "c2"><tt>direct_mask_range_hashing</tt></span></a></tt>,
- then
- <pre>
-<a href="hash_standard_resize_policy.html"><span class=
-"c2"><tt>hash_standard_resize_policy</tt></span></a>&lt;
- <a href="hash_exponential_size_policy.html"><span class=
-"c2"><tt>hash_exponential_size_policy</tt></span></a>&lt;
- <b>typename</b> <a href=
-"#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>::size_type&gt;,
- <a href="hash_load_check_resize_trigger.html"><span class=
-"c2"><tt>hash_load_check_resize_trigger</tt></span></a>&lt;
- <b>typename</b> <a href=
-"#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>::size_type&gt;,
- <b>false</b>,
- <b>typename</b> <a href=
-"#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>::size_type&gt;
-</pre>otherwise,
- <pre>
-<a href="hash_standard_resize_policy.html"><span class=
-"c2"><tt>hash_standard_resize_policy</tt></span></a>&lt;
- <a href="hash_exponential_size_policy.html"><span class=
-"c2"><tt>hash_exponential_size_policy</tt></span></a>&lt;
- <b>typename</b> <a href=
-"#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>::size_type&gt;,
- <a href="hash_load_check_resize_trigger.html"><span class=
-"c2"><tt>hash_load_check_resize_trigger</tt></span></a>&lt;
- <b>typename</b> <a href=
-"#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>::size_type&gt;,
- <b>false</b>,
- <b>typename</b> <a href=
-"#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>::size_type&gt;
-</pre>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Store_Hash218262104" id=
-"Store_Hash218262104"><b>bool</b> Store_Hash </a>
-</pre>
- </td>
-
- <td>
- <p>Indicates whether the hash value will be stored along
- with each key.</p>
-
- <p>If <tt><a href=
- "#hash_fn2015995"><tt>hash_fn</tt></a></tt> is <a href=
- "null_hash_fn.html"><span class=
- "c2"><tt>null_hash_fn</tt></span></a>, then the container
- will not compile if this value is
- <tt><b>true</b></tt></p>
- </td>
-
- <td>
- <pre>
-<tt><b>false</b></tt>
-</pre>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator </a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>
- <pre>
-std::allocator&lt;<b>char</b>&gt;
-</pre>
- </td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="basic_hash_table.html"><span class=
-"c2"><tt>basic_hash_table</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Types and
- Constants</a></h2>
-
- <h3><a name="link4" id="link4">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="hash_fn2015995" id="hash_fn2015995">hash_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Hash_Fn1515835"><tt>Hash_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Hash functor type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="eq_fn80245" id="eq_fn80245">eq_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Eq_Fn60085"><tt>Eq_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Equivalence functor type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="resize_policy4084493169" id=
-"resize_policy4084493169">resize_policy</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Resize_Policy566860465"><tt>Resize_Policy</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Resize policy type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="comb_hash_fn1883611199" id=
-"comb_hash_fn1883611199">comb_hash_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Comb_Hash_Fn320611039"><tt>Comb_Hash_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Combining hash functor type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Public Methods</a></h2>
-
- <h3><a name="link6" id="link6">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- cc_hash_table
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- cc_hash_table
- (<b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking some policy objects. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#Hash_Fn1515835"><tt>Hash_Fn</tt></a> object of
- the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- cc_hash_table
- (<b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking some policy objects. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, and <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- cc_hash_table
- (<b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn,
- <b>const</b> <a href=
-"#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> &amp;r_comb_hash_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking some policy objects. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object, and <span class=
- "c1"><tt>r_comb_hash_fn</tt></span> will be copied by the
- <a href=
- "#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a>
- object of the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- cc_hash_table
- (<b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn,
- <b>const</b> <a href=
-"#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> &amp;r_comb_hash_fn,
- <b>const</b> <a href=
-"#resize_policy4084493169"><tt>resize_policy</tt></a> &amp;r_resize_policy)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking some policy objects. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object, <span class=
- "c1"><tt>r_comb_hash_fn</tt></span> will be copied by the
- <a href=
- "#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a>
- object of the container object, and <span class=
- "c1"><tt>r_resize_policy</tt></span> will be copied by
- the <a href=
- "#resize_policy4084493169"><tt>resize_policy</tt></a>
- object of the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- cc_hash_table
- (It first_it,
- It last_it)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of
- value_types. The value_types between <span class=
- "c1"><tt>first_it</tt></span> and <span class=
- "c1"><tt>last_it</tt></span> will be inserted into the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- cc_hash_table
- (It first_it,
- It last_it,
- <b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of value_types
- and some policy objects. The value_types between
- <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- cc_hash_table
- (It first_it,
- It last_it,
- <b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of value_types
- and some policy objects The value_types between
- <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, and <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- cc_hash_table
- (It first_it,
- It last_it,
- <b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn,
- <b>const</b> <a href=
-"#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> &amp;r_comb_hash_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of value_types
- and some policy objects The value_types between
- <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object, and <span class=
- "c1"><tt>r_comb_hash_fn</tt></span> will be copied by the
- <a href=
- "#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a>
- object of the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- cc_hash_table
- (It first_it,
- It last_it,
- <b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn,
- <b>const</b> <a href=
-"#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> &amp;r_comb_hash_fn,
- <b>const</b> <a href=
-"#resize_policy4084493169"><tt>resize_policy</tt></a> &amp;r_resize_policy)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of value_types
- and some policy objects The value_types between
- <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object, <span class=
- "c1"><tt>r_comb_hash_fn</tt></span> will be copied by the
- <a href=
- "#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a>
- object of the container object, and <span class=
- "c1"><tt>r_resize_policy</tt></span> will be copied by
- the <a href=
- "#resize_policy4084493169"><tt>resize_policy</tt></a>
- object of the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- cc_hash_table
- (<b>const</b> <span class=
-"c2"><tt>cc_hash_table</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b>
- ~cc_hash_table
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<span class="c2"><tt>cc_hash_table</tt></span> &amp;
- <b>operator</b>=
- (<b>const</b> <span class=
-"c2"><tt>cc_hash_table</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Assignment operator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class=
-"c2"><tt>cc_hash_table</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Policy Access Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> &amp;
- get_comb_hash_fn
- ()
-</pre>
- </td>
-
- <td>
- <p>Access to the <a href=
- "#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a>
- object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>const</b> <a href=
-"#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a> &amp;
- get_comb_hash_fn
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Const access to the <a href=
- "#comb_hash_fn1883611199"><tt>comb_hash_fn</tt></a>
- object.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_tag.html
deleted file mode 100644
index 1923e20fb..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/cc_hash_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>cc_hash_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>cc_hash_tag</tt> Interface</h1>
-
- <p>Collision-chaining hash data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="basic_hash_tag.html"><span class=
-"c2"><tt>basic_hash_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_gcc.png
deleted file mode 100644
index fde6b41bf..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_local.png
deleted file mode 100644
index 2449e1de3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_msvc.png
deleted file mode 100644
index 11dca77fc..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ccgp_hash_random_int_subscript_timing_test_insert_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/checked_by_tidy.gif b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/checked_by_tidy.gif
deleted file mode 100644
index 47c2c4859..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/checked_by_tidy.gif
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/concepts.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/concepts.html
deleted file mode 100644
index 9f6c22462..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/concepts.html
+++ /dev/null
@@ -1,118 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Concepts</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Concepts</h1>
-
- <h2><a name="concepts_find_and_range_iterators" id=
- "concepts_find_and_range_iterators">Point and Range Methods and
- Iterators</a></h2>
-
- <p>A point-type iterator is an iterator that refers to a
- specific element, <i>e.g.</i> as returned through an
- associative-container's <tt>find</tt> method; a range-type
- iterator is an iterator that is used to go over a sequence of
- elements, <i>e.g.</i>, as returned by a container's
- <tt>find</tt> method. A point-type method is a method that
- returns a point-type iterator; a range-type method is a method
- that returns a range-type iterator.</p>
-
- <p>For most containers, these types are synonymous; for
- self-organizing containers, such as hash-based containers or
- priority queues, these are inherently different (in any
- implementation, including that of the STL), but in
- <tt>pb_ds</tt> this is made explicit - they are distinct
- types.</p>
-
-
- <h2><a name="invalidation_guarantees" id=
- "invalidation_guarantees">Invalidation Guarantees</a></h2>
-
- <p>If one manipulates a container object, then iterators
- previously obtained from it can be invalidated. In some cases a
- previously-obtained iterator cannot be de-referenced; in other
- cases, the iterator's next or previous element might have
- changed unpredictably. This corresponds exactly to the question
- whether a point-type or range-type iterator (see previous
- concept) is valid or not. In <tt>pb_ds</tt> one can query a
- container (in compile time) what are its invalidation
- guarantees.</p>
-
- <h2><a name="prm_sec" id="prm_sec">Primary and Secondary Keys
- and Associative Containers</a></h2>
-
- <p>In <tt>pb_ds</tt> there are no associative containers which
- allow multiple values with equivalent keys (such as the STL's
- <tt>std::multimap</tt>, for example). Instead, one maps the
- unique part of a key - the primary key, into an
- associative-container of the (originally) non-unique parts of
- the key - the secondary key. A primary associative-container is
- an associative container of primary keys; a secondary
- associative-container is an associative container of secondary
- keys.</p>
-
-
- <h2><a name="concepts_null_policies" id=
- "concepts_null_policies">Null Policy Classes</a></h2>
-
- <p>Associative containers are typically parametrized by
- various policies. For example, a hash-based associative
- container is parametrized by a hash-functor, transforming each
- key into an non-negative numerical type. Each such value is
- then further mapped into a position within the table. The
- mapping of a key into a position within the table is therefore
- a two-step process.</p>
-
- <p>In some cases, instantiations are <i>redundant</i>. For
- example, when the keys are integers, it is possible to use a
- <i>redundant</i> hash policy, which transforms each key into
- its value.</p>
-
- <p>In some other cases, these policies are <i>irrelevant</i>.
- For example, a hash-based associative container might transform
- keys into positions within a table by a different method than
- the two-step method described above. In such a case, the hash
- functor is simply irrelevant.</p>
-
- <p><tt>pb_ds</tt> uses special pre-defined "null policies"
- classes for these cases. Some null policies in <tt>pb_ds</tt>
- are:</p>
-
- <ol>
- <li><a href=
- "null_mapped_type.html"><tt>null_mapped_type</tt></a></li>
-
- <li><a href=
- "null_tree_node_update.html"><tt>null_tree_node_update</tt></a></li>
-
- <li><a href=
- "null_trie_node_update.html"><tt>null_trie_node_update</tt></a></li>
-
- <li><a href=
- "null_hash_fn.html"><tt>null_hash_fn</tt></a></li>
-
- <li><a href=
- "null_probe_fn.html"><tt>null_probe_fn</tt></a></li>
- </ol>
-
- <p>A "set" in <tt>pb_ds</tt>, for example, is an associative
- container with its <tt>Data_Parameter</tt> instantiated by
- <a href="null_mapped_type.html"><tt>null_mapped_type</tt></a>.
- <a href=
- "tree_based_containers.html#invariants">Design::Tree-Based
- Containers::Node Invariants</a> explains another case where a
- null policy is needed.</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/contact.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/contact.html
deleted file mode 100644
index 3d506c975..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/contact.html
+++ /dev/null
@@ -1,22 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Contact</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Contact</h1>
-
- <p>For anything relevant, please write to <a href=
- "mailto:pbassoc@gmail.com">pbassoc@gmail.com</a></p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_base.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_base.html
deleted file mode 100644
index 359e02459..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_base.html
+++ /dev/null
@@ -1,1063 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>container_base Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>container_base</tt> Interface</h1>
-
- <p>An abstract basic associative container.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Key2501" id="Key2501"><b>typename</b> Key</a>
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a>
-</pre>
- </td>
-
- <td>
- <p>Mapped type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Tag278938" id="Tag278938"><b>class</b> Tag</a>
-</pre>
- </td>
-
- <td>
- <p>Data structure tag.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Policy_Tl42017403" id=
-"Policy_Tl42017403"><b>class</b> Policy_Tl</a>
-</pre>
- </td>
-
- <td>
- <p>Policy typelist.</p>
-
- <p>Contains subclasses' policies.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator</a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>-</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">General Container
- Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#Allocator35940069"><tt>Allocator</tt></a>::size_type
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="difference_type868028452" id=
-"difference_type868028452">difference_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#Allocator35940069"><tt>Allocator</tt></a>::difference_type
-</pre>
- </td>
-
- <td>
- <p>Difference type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">Categories</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="container_category1247973216" id=
-"container_category1247973216">container_category</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Tag278938"><tt>Tag</tt></a>
-</pre>
- </td>
-
- <td>
- <p>The underlying mapped-structure tag of the
- container.</p>
-
- <p>This is one of:</p>
-
- <ol>
- <li><a href="cc_hash_tag.html"><span class=
- "c2"><tt>cc_hash_tag</tt></span></a></li>
-
- <li><a href="gp_hash_tag.html"><span class=
- "c2"><tt>gp_hash_tag</tt></span></a></li>
-
- <li><a href="rb_tree_tag.html"><span class=
- "c2"><tt>rb_tree_tag</tt></span></a></li>
-
- <li><a href="ov_tree_tag.html"><span class=
- "c2"><tt>ov_tree_tag</tt></span></a></li>
-
- <li><a href="splay_tree_tag.html"><span class=
- "c2"><tt>splay_tree_tag</tt></span></a></li>
-
- <li><a href="pat_trie_tag.html"><span class=
- "c2"><tt>pat_trie_tag</tt></span></a></li>
-
- <li><a href="list_update_tag.html"><span class=
- "c2"><tt>list_update_tag</tt></span></a></li>
- </ol>
- </td>
- </tr>
- </table>
-
- <h3><a name="link5" id="link5">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="allocator48440069" id="allocator48440069">allocator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Allocator35940069"><tt>Allocator</tt></a>
-</pre>
- </td>
-
- <td>
- <p><a href="#Allocator35940069"><tt>Allocator</tt></a>
- type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link6" id="link6">Key-Type Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="key_type10393186" id="key_type10393186">key_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href="#Key2501"><tt>Key</tt></a>&gt;::other::value_type
-</pre>
- </td>
-
- <td>
- <p><a href="#Key2501"><tt>Key</tt></a> type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="key_reference2411522399" id=
-"key_reference2411522399">key_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#key_type10393186"><tt>key_type</tt></a>&gt;::other::reference
-</pre>
- </td>
-
- <td>
- <p><a href="#Key2501"><tt>Key</tt></a> reference
- type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_key_reference3185471705" id=
-"const_key_reference3185471705">const_key_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#key_type10393186"><tt>key_type</tt></a>&gt;::other::const_reference
-</pre>
- </td>
-
- <td>
- <p>Const key reference type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="key_pointer1299054769" id=
-"key_pointer1299054769">key_pointer</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#key_type10393186"><tt>key_type</tt></a>&gt;::other::pointer
-</pre>
- </td>
-
- <td>
- <p><a href="#Key2501"><tt>Key</tt></a> pointer type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_key_pointer3735194427" id=
-"const_key_pointer3735194427">const_key_pointer</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#key_type10393186"><tt>key_type</tt></a>&gt;::other::const_pointer
-</pre>
- </td>
-
- <td>
- <p>Const key pointer type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Mapped-Type Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="mapped_type1308374436" id=
-"mapped_type1308374436">mapped_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Mapped318655"><tt>Mapped</tt></a>
-</pre>
- </td>
-
- <td>
- <p><a href="#Mapped318655"><tt>Mapped</tt></a> type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="mapped_reference4153801225" id=
-"mapped_reference4153801225">mapped_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#mapped_type1308374436"><tt>mapped_type</tt></a>&gt;::other::reference
-</pre>
- </td>
-
- <td>
- <p><a href="#Mapped318655"><tt>Mapped</tt></a> reference
- type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_mapped_reference2113216667" id=
-"const_mapped_reference2113216667">const_mapped_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#mapped_type1308374436"><tt>mapped_type</tt></a>&gt;::other::const_reference
-</pre>
- </td>
-
- <td>
- <p>Const mapped reference type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="mapped_pointer337953771" id=
-"mapped_pointer337953771">mapped_pointer</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#mapped_type1308374436"><tt>mapped_type</tt></a>&gt;::other::pointer
-</pre>
- </td>
-
- <td>
- <p><a href="#Mapped318655"><tt>Mapped</tt></a> pointer
- type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_mapped_pointer4207700301" id=
-"const_mapped_pointer4207700301">const_mapped_pointer</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#mapped_type1308374436"><tt>mapped_type</tt></a>&gt;::other::const_pointer
-</pre>
- </td>
-
- <td>
- <p>Const mapped pointer type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link8" id="link8">Value-Type Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="value_type279018186" id=
-"value_type279018186">value_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<br />
-If <a href="#Mapped318655"><tt>Mapped</tt></a> is <a href=
-"null_mapped_type.html"><span class=
-"c2"><tt>null_mapped_type</tt></span></a>, then <a href=
-"#Key2501"><tt>Key</tt></a><br />
-Otherwise, <a href="#Mapped318655"><tt>Mapped</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Value type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="reference54418471" id="reference54418471">reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#value_type279018186"><tt>value_type</tt></a>&gt;::other::reference
-</pre>
- </td>
-
- <td>
- <p>Value reference type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_reference495461441" id=
-"const_reference495461441">const_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#value_type279018186"><tt>value_type</tt></a>&gt;::other::const_reference
-</pre>
- </td>
-
- <td>
- <p>Const value <a href=
- "#reference54418471"><tt>reference</tt></a> type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="pointer2179769" id="pointer2179769">pointer</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#value_type279018186"><tt>value_type</tt></a>&gt;::other::pointer
-</pre>
- </td>
-
- <td>
- <p>Value pointer type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_pointer878814947" id=
-"const_pointer878814947">const_pointer</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#value_type279018186"><tt>value_type</tt></a>&gt;::other::const_pointer
-</pre>
- </td>
-
- <td>
- <p>Const Value <a href=
- "#pointer2179769"><tt>pointer</tt></a> type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link9" id="link9">Iterator Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_point_iterator2364676009" id=
-"const_point_iterator2364676009">const_point_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Const point-type iterator.
-</pre>
- </td>
-
- <td>
- <p>Const point-type iterator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="point_iterator2789896775" id=
-"point_iterator2789896775">point_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<br />
-Point-type iterator.<br />
-If <a href="#Mapped318655"><tt>Mapped</tt></a> is <a href=
-"null_mapped_type.html"><span class=
-"c2"><tt>null_mapped_type</tt></span></a>, then this is synonymous to <a href="#const_point_iterator2364676009"><tt>const_point_iterator</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Point-type iterator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_iterator98626788" id=
-"const_iterator98626788">const_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Const range-type iterator.
-</pre>
- </td>
-
- <td>
- <p>Const range-type iterator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="iterator10418194" id="iterator10418194">iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<br />
-Range-type iterator.<br />
-If <a href="#Mapped318655"><tt>Mapped</tt></a> is <a href=
-"null_mapped_type.html"><span class=
-"c2"><tt>null_mapped_type</tt></span></a>, then this is synonymous to <a href="#const_iterator98626788"><tt>const_iterator</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Range-type iterator.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link10" id="link10">Public Methods</a></h2>
-
- <h3><a name="link11" id="link11">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b>
- ~container_base
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link12" id="link12">Information Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- size
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the number of distinct <a href=
- "#value_type279018186"><tt>value_type</tt></a> objects
- the container object is storing.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- max_size
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns an upper bound on the number of distinct
- <a href="#value_type279018186"><tt>value_type</tt></a>
- objects this container can store.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- empty
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns whether the container object is not storing
- any <a href=
- "#value_type279018186"><tt>value_type</tt></a>
- objects.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link13" id="link13">Insert Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-std::pair&lt;<a href=
-"#point_iterator2789896775"><tt>point_iterator</tt></a>, <b>bool</b>&gt;
- insert
- (<a href=
-"#const_reference495461441"><tt>const_reference</tt></a> r_val)
-</pre>
- </td>
-
- <td>
- <p>Inserts a <a href=
- "#value_type279018186"><tt>value_type</tt></a> object. If
- no <a href="#value_type279018186"><tt>value_type</tt></a>
- with <span class="c1"><tt>r_val</tt></span>'s key was in
- the container object, inserts and returns (<a href=
- "#point_iterator2789896775"><tt>point_iterator</tt></a>
- object associated with <span class=
- "c1"><tt>r_val</tt></span>, <tt><b>true</b></tt>);
- otherwise just returns (<a href=
- "#point_iterator2789896775"><tt>point_iterator</tt></a>
- object associated with <span class=
- "c1"><tt>r_val</tt></span>'s key,
- <tt><b>false</b></tt>).</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#mapped_reference4153801225"><tt>mapped_reference</tt></a>
- <b>operator</b>[]
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key)
-</pre>
- </td>
-
- <td>
- <p>Subscript operator.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link14" id="link14">Find Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#point_iterator2789896775"><tt>point_iterator</tt></a>
- find
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key)
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#point_iterator2789896775"><tt>point_iterator</tt></a>
- corresponding to the <a href=
- "#value_type279018186"><tt>value_type</tt></a> with
- <span class="c1"><tt>r_key</tt></span> as its key, or the
- <a href=
- "#point_iterator2789896775"><tt>point_iterator</tt></a>
- corresponding to the just-after-last entry if no such
- <a href=
- "#value_type279018186"><tt>value_type</tt></a>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href=
-"#const_point_iterator2364676009"><tt>const_point_iterator</tt></a>
- find
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#const_point_iterator2364676009"><tt>const_point_iterator</tt></a>
- corresponding to the <a href=
- "#value_type279018186"><tt>value_type</tt></a> with
- <span class="c1"><tt>r_key</tt></span> as its key, or the
- <a href=
- "#const_point_iterator2364676009"><tt>const_point_iterator</tt></a>
- corresponding to the just-after-last entry if no such
- <a href=
- "#value_type279018186"><tt>value_type</tt></a>.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link15" id="link15">Erase Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>bool</b>
- erase
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key)
-</pre>
- </td>
-
- <td>
- <p>Erases the <a href=
- "#value_type279018186"><tt>value_type</tt></a> associated
- with <span class="c1"><tt>r_key</tt></span>. returns
- <tt><b>false</b></tt> iff <span class=
- "c1"><tt>r_key</tt></span> was not contained.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> Pred&gt;
-<a href="#size_type55424436"><tt>size_type</tt></a>
- erase_if
- (Pred prd)
-</pre>
- </td>
-
- <td>
- <p>Erases any <a href=
- "#value_type279018186"><tt>value_type</tt></a> satisfying
- the predicate <span class="c1"><tt>prd</tt></span> (this
- is transactional, either all matching <a href=
- "#value_type279018186"><tt>value_type</tt></a>s are
- erased, or, if an exception is thrown (for types whose
- erase can throw an exception) none); returns the number
- of <a href=
- "#value_type279018186"><tt>value_type</tt></a>s
- erased.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- clear
- ()
-</pre>
- </td>
-
- <td>
- <p>Clears the container object.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link16" id="link16">Iteration Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#iterator10418194"><tt>iterator</tt></a>
- begin
- ()
-</pre>
- </td>
-
- <td>
- <p>Returns an <a href=
- "#iterator10418194"><tt>iterator</tt></a> corresponding
- to the first <a href=
- "#value_type279018186"><tt>value_type</tt></a> in the
- container.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#const_iterator98626788"><tt>const_iterator</tt></a>
- begin
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a>
- corresponding to the first <a href=
- "#value_type279018186"><tt>value_type</tt></a> in the
- container.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#iterator10418194"><tt>iterator</tt></a>
- end
- ()
-</pre>
- </td>
-
- <td>
- <p>Returns an <a href=
- "#iterator10418194"><tt>iterator</tt></a> corresponding
- to the just-after-last <a href=
- "#value_type279018186"><tt>value_type</tt></a> in the
- container.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#const_iterator98626788"><tt>const_iterator</tt></a>
- end
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a>
- corresponding to the just-after-last <a href=
- "#value_type279018186"><tt>value_type</tt></a> in the
- container.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.png
deleted file mode 100644
index 52553278c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.svg b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.svg
deleted file mode 100644
index 3b5a98189..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_cd.svg
+++ /dev/null
@@ -1,418 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Created with Inkscape (http://www.inkscape.org/) -->
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://web.resource.org/cc/"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- width="11in"
- height="8.5in"
- id="svg2"
- sodipodi:version="0.32"
- inkscape:version="0.43"
- version="1.0"
- sodipodi:docbase="/mnt/share/src/policy_based_data_structures/current/pb_ds/doc"
- sodipodi:docname="container_cd.svg"
- inkscape:export-filename="/mnt/share/src/policy_based_data_structures/current/pb_ds/doc/container_cd.png"
- inkscape:export-xdpi="90"
- inkscape:export-ydpi="90">
- <defs
- id="defs4">
- <marker
- inkscape:stockid="Arrow1Mstart"
- orient="auto"
- refY="0.0"
- refX="0.0"
- id="Arrow1Mstart"
- style="overflow:visible">
- <path
- id="path3311"
- d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
- style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none"
- transform="scale(0.4)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Sstart"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Sstart"
- style="overflow:visible">
- <path
- id="path3319"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(0.3,0,0,0.3,-1.5,0)" />
- </marker>
- <marker
- inkscape:stockid="Arrow1Sstart"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow1Sstart"
- style="overflow:visible">
- <path
- id="path3337"
- d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
- style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
- transform="scale(0.2,0.2)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Send"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Send"
- style="overflow:visible">
- <path
- id="path3316"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(-0.3,0,0,-0.3,1.5,0)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Mend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Mend"
- style="overflow:visible">
- <path
- id="path3322"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(-0.6,0,0,-0.6,3,0)" />
- </marker>
- <marker
- inkscape:stockid="Arrow1Lend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow1Lend"
- style="overflow:visible">
- <path
- id="path3346"
- d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
- style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
- transform="scale(-0.8,-0.8)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Lstart"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Lstart"
- style="overflow:visible">
- <path
- id="path3331"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(1.1,0,0,1.1,-5.5,0)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Lend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Lend"
- style="overflow:visible">
- <path
- id="path3328"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(-1.1,0,0,-1.1,5.5,0)" />
- </marker>
- </defs>
- <sodipodi:namedview
- id="base"
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1.0"
- inkscape:pageopacity="0.0"
- inkscape:pageshadow="2"
- inkscape:zoom="2"
- inkscape:cx="396.81316"
- inkscape:cy="280"
- inkscape:document-units="in"
- inkscape:current-layer="layer1"
- showguides="true"
- inkscape:guide-bbox="true"
- inkscape:window-width="1278"
- inkscape:window-height="973"
- inkscape:window-x="0"
- inkscape:window-y="0"
- gridtolerance="0.125in"
- guidetolerance="0.125in">
- <sodipodi:guide
- orientation="horizontal"
- position="629"
- id="guide1307" />
- <sodipodi:guide
- orientation="horizontal"
- position="449"
- id="guide1309" />
- <sodipodi:guide
- orientation="horizontal"
- position="269"
- id="guide1311" />
- <sodipodi:guide
- orientation="vertical"
- position="496"
- id="guide1313" />
- <sodipodi:guide
- orientation="vertical"
- position="361"
- id="guide1315" />
- <sodipodi:guide
- orientation="vertical"
- position="226"
- id="guide1317" />
- <sodipodi:guide
- orientation="vertical"
- position="631"
- id="guide1319" />
- <sodipodi:guide
- orientation="vertical"
- position="766"
- id="guide1321" />
- <sodipodi:guide
- orientation="vertical"
- position="91"
- id="guide1345" />
- <sodipodi:guide
- orientation="vertical"
- position="901"
- id="guide1347" />
- <sodipodi:guide
- orientation="horizontal"
- position="539"
- id="guide3390" />
- <sodipodi:guide
- orientation="horizontal"
- position="359"
- id="guide3392" />
- <sodipodi:guide
- orientation="vertical"
- position="280.5"
- id="guide3324" />
- <sodipodi:guide
- orientation="vertical"
- position="172"
- id="guide3326" />
- <sodipodi:guide
- orientation="vertical"
- position="388"
- id="guide3328" />
- <sodipodi:guide
- orientation="vertical"
- position="711.5"
- id="guide3340" />
- </sodipodi:namedview>
- <metadata
- id="metadata7">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- <dc:creator>
- <cc:Agent>
- <dc:title>Benjamin Kosnik</dc:title>
- </cc:Agent>
- </dc:creator>
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <g
- inkscape:label="Layer 1"
- inkscape:groupmode="layer"
- id="layer1">
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect1425"
- width="141.64481"
- height="23.200001"
- x="209.57762"
- y="382.56177" />
- <rect
- y="382.56177"
- x="425.57761"
- height="23.200001"
- width="141.64481"
- id="rect3376"
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect3378"
- width="141.64481"
- height="23.200001"
- x="640.77765"
- y="382.56177" />
- <text
- sodipodi:linespacing="100%"
- id="use1329"
- y="397.09772"
- x="497.20001"
- style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
- xml:space="preserve"><tspan
- sodipodi:role="line"
- id="tspan1703"
- x="497.20001"
- y="397.09772">list_update</tspan><tspan
- sodipodi:role="line"
- id="tspan1705"
- x="497.20001"
- y="406.69772" /></text>
- <text
- xml:space="preserve"
- style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="712.40002"
- y="397.09772"
- id="use1337"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1707"
- x="712.40002"
- y="397.09772">basic_hash_table</tspan></text>
- <text
- xml:space="preserve"
- style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="282"
- y="397.09772"
- id="text1339"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1701"
- x="282"
- y="397.09772">basic_tree</tspan></text>
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect3418"
- width="141.64481"
- height="23.200001"
- x="101.57762"
- y="472.5618" />
- <rect
- y="472.5618"
- x="317.57761"
- height="23.200001"
- width="141.64481"
- id="rect3420"
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect3422"
- width="141.64481"
- height="23.200001"
- x="533.57764"
- y="472.5618" />
- <rect
- y="472.5618"
- x="748.77765"
- height="23.200001"
- width="141.64481"
- id="rect3424"
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <text
- xml:space="preserve"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="171.20001"
- y="486.29773"
- id="text3394"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1715"
- x="171.20001"
- y="486.29773">tree</tspan><tspan
- sodipodi:role="line"
- id="tspan1717"
- x="171.20001"
- y="495.89773" /></text>
- <text
- sodipodi:linespacing="100%"
- id="text3400"
- y="486.29773"
- x="386.39999"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
- xml:space="preserve"><tspan
- sodipodi:role="line"
- id="tspan1709"
- x="386.39999"
- y="486.29773">trie</tspan><tspan
- sodipodi:role="line"
- id="tspan1711"
- x="386.39999"
- y="495.89773" /></text>
- <text
- sodipodi:linespacing="100%"
- id="text3406"
- y="486.29773"
- x="601.20001"
- style="font-size:9.60000038px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- xml:space="preserve"><tspan
- sodipodi:role="line"
- id="tspan1713"
- x="601.20001"
- y="486.29773">cc_hash_table</tspan></text>
- <text
- xml:space="preserve"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="818"
- y="486.29773"
- id="text3412"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1719"
- x="818"
- y="486.29773">gp_hash_table</tspan></text>
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect3380"
- width="141.64481"
- height="23.200001"
- x="425.57764"
- y="292.56177" />
- <text
- xml:space="preserve"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="497.20001"
- y="307.09772"
- id="text1323"
- sodipodi:linespacing="100%"
- inkscape:export-xdpi="90"
- inkscape:export-ydpi="90"
- inkscape:export-filename="/mnt/share/src/policy_based_data_structures/pb_ds_images/container_diagram.png"><tspan
- sodipodi:role="line"
- id="tspan1369"
- x="497.20001"
- y="307.09772">container_base</tspan></text>
- <path
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:0.97031623px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
- d="M 170.97058,472.5 L 170.97058,451 L 387.51871,450 L 387.51871,472.5"
- id="path2244" />
- <path
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="M 280.5,450.53297 L 280.5,410.62445"
- id="path3332" />
- <path
- id="path3353"
- d="M 601.47058,472.5 L 601.47058,451 L 818.01871,450 L 818.01871,472.5"
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:0.97031623px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
- <path
- id="path3355"
- d="M 711,450.53297 L 711,410.62445"
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <path
- id="path3344"
- d="M 281.18218,383.28102 L 281.18218,361.78102 L 711.79281,360.78102 L 711.79281,383.28102"
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.3682909px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
- <path
- id="path3347"
- d="M 497.75146,383.49616 L 497.75146,322.77107"
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- </g>
-</svg>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_tag.html
deleted file mode 100644
index de187a94d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/container_tag.html
+++ /dev/null
@@ -1,24 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>container _tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>container _tag</tt> Interface</h1>
-
- <p>Basic data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/counter_lu_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/counter_lu_policy.html
deleted file mode 100644
index d9d5112c0..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/counter_lu_policy.html
+++ /dev/null
@@ -1,259 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>counter_lu_policy Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>counter_lu_policy</tt> Interface</h1>
-
- <p>A list-update policy that moves elements to the front of the
- list based on the counter algorithm.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/list_update_policy.hpp"><tt>list_update_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Max_Count39887466" id=
-"Max_Count39887466">size_t Max_Count </a>
-</pre>
- </td>
-
- <td>
- <p>Maximum count.</p>
-
- <p>When some element is accessed this number of times, it
- will be moved to the front of the list.</p>
- </td>
-
- <td>5</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator </a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
-
- <p>This is used only for definitions, e.g., the size
- type.</p>
- </td>
-
- <td>
- <pre>
-std::allocator&lt;<b>char</b>&gt;
-</pre>
- </td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="allocator48440069" id="allocator48440069">allocator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Allocator35940069"><tt>Allocator</tt></a>
-</pre>
- </td>
-
- <td>
- <p><a href="#Allocator35940069"><tt>Allocator</tt></a>
- type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="max_count52407466" id="max_count52407466">max_count</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Max_Count39887466"><tt>Max_Count</tt></a>
-}
-</pre>
- </td>
-
- <td>
- <p>Maximum count.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::size_type
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link5" id="link5">Metadata-Type
- Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_type2849297114" id=
-"metadata_type2849297114">metadata_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Some class containing a counter.
-</pre>
- </td>
-
- <td>
- <p>Metadata on which this functor operates.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_reference583863863" id=
-"metadata_reference583863863">metadata_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#metadata_type2849297114"><tt>metadata_type</tt></a>&gt;::other::reference
-</pre>
- </td>
-
- <td>
- <p>Reference to metadata on which this functor
- operates.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link6" id="link6">Public Methods</a></h2>
-
- <h3><a name="link7" id="link7">Metadata Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#metadata_type2849297114"><tt>metadata_type</tt></a>
- <b>operator</b>()
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Creates a metadata object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>bool</b>
- <b>operator</b>()
- (<a href=
-"#metadata_reference583863863"><tt>metadata_reference</tt></a> r_metadata) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Decides whether a metadata object should be moved to
- the front of the list.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/design.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/design.html
deleted file mode 100644
index e83bd4dd2..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/design.html
+++ /dev/null
@@ -1,96 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Design</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Design</h1>
-
- <p>The <tt>pb_ds</tt> namespace contains:</p>
-
- <ol>
- <li>Exception classes (see <a href=
- "interface.html#exceptions_common">Interface::Exceptions::Common</a>)</li>
-
- <li>Invalidation-guarantee tags (see <a href=
- "ds_gen.html#inv_guar">Design::Invalidation Guarantees</a>
- and <a href=
- "interface.html#ds_inv_tag">Interface::Data-Structure Tags
- and Traits::Invalidation-Guarantee Tags</a>).</li>
-
- <li>Associative Containers (see <a href=
- "tree_based_containers.html">Design::Associative
- Containers::Tree-Based Containers</a>, <a href=
- "trie_based_containers.html">Design::Associative
- Containers::Trie-Based Containers</a>, <a href=
- "hash_based_containers.html">Design::Associative
- Containers::Hash-Based Containers</a>, and <a href=
- "lu_based_containers.html">Design::Associative
- Containers::List-Based Containers</a>, and <a href=
- "interface.html#containers_assoc">Interface::Containers::Associative
- Containers</a>).</li>
-
- <li>Associative Container tags and traits
- (see <a href="ds_gen.html">Design::Associative
- Containers::Data-Structure Genericity</a>, <a href=
- "interface.html#ds_ts_assoc">Interface::Data-Structure Tags
- and Traits::Data-Structure Tags::Associative-Containers</a>,
- and <a href=
- "interface.html#container_traits">Interface::Data-Structure Tags and
- Traits::Data-Structure
- Traits::Associative-Containers</a>).</li>
-
- <li>Associative Container policies (see
- <a href="tree_based_containers.html">Design::Associative
- Containers::Tree-Based Containers</a>, <a href=
- "trie_based_containers.html">Design::Associative
- Containers::Trie-Based Containers</a>, <a href=
- "hash_based_containers.html">Design::Associative
- Containers::Hash-Based Containers</a>, and <a href=
- "lu_based_containers.html">Design::Associative
- Containers::List-Based Containers</a>, and <a href=
- "interface.html#ds_policy_classes">Interface::Container
- Policy Classes</a>).</li>
-
-
- <li>Mapped types for setting the mapping semantics of
- associative containers (see <a href=
- "tutorial.html#assoc_ms">Tutorial::Associative
- Containers::Associative Containers Others than Maps</a> and
- <a href="interface.html#ds_pol">Interface::Mapped-Type
- Policies</a>).</li>
-
-
- <li>Priority Queues (see <a href="pq_design.html">Design::Priority
- Queues</a> and <a href=
- "interface.html#containers_pq">Interface::Containers::Priority
- Queues</a>).</li>
-
- <li>Priority Queue tags and traits
- (see <a href="pq_design.html#pq_traits">Design::Priority
- Queues::Traits</a>, <a href=
- "interface.html#ds_ts_pq">Interface::Data-Structure Tags and
- Traits::Data-Structure Tags::Priority Queues</a>, and
- <a href="interface.html#container_traits">Interface::Data-Structure
- Tags and Traits::Data-Structure Traits::Priority
- Queues</a>).</li>
- </ol>
-
-
- <p><a href="assoc_design.html">Associative-Container Design</a>
- describes associative-container design.</p>
-
- <p><a href="pq_design.html">Priority-Queue Design</a> describes
- priority-queue design.</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/different_underlying_dss.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/different_underlying_dss.png
deleted file mode 100644
index adee12636..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/different_underlying_dss.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mask_range_hashing.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mask_range_hashing.html
deleted file mode 100644
index 19f8621c2..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mask_range_hashing.html
+++ /dev/null
@@ -1,167 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>direct_mask_range_hashing Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>direct_mask_range_hashing</tt> Interface</h1>
-
- <p>A mask range-hashing class (uses a bit-mask).</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Size_Type42920436" id=
-"Size_Type42920436"><b>typename</b> Size_Type </a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
-
- <td>size_t</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Size_Type42920436"><tt>Size_Type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link4" id="link4">Public Methods</a></h2>
-
- <h3><a name="link5" id="link5">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class=
-"c2"><tt>direct_mask_range_hashing</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link6" id="link6">Protected Methods</a></h2>
-
- <h3><a name="link7" id="link7">Notification Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_resized
- (<a href="#size_type55424436"><tt>size_type</tt></a> size)
-</pre>
- </td>
-
- <td>
- <p>Notifies the policy object that the container's size
- has changed to <span class="c1"><tt>size</tt></span>.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link8" id="link8">Operators.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- <b>operator</b>()
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> hash) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Transforms the hash value <span class=
- "c1"><tt>hash</tt></span> into a ranged-hash value (using
- a bit-mask).</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mod_range_hashing.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mod_range_hashing.html
deleted file mode 100644
index f3f9295d4..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/direct_mod_range_hashing.html
+++ /dev/null
@@ -1,144 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>direct_mod_range_hashing Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>direct_mod_range_hashing</tt> Interface</h1>
-
- <p>A mod range-hashing class (uses the modulo function).</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Size_Type42920436" id=
-"Size_Type42920436"><b>typename</b> Size_Type </a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
-
- <td>size_t</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Size_Type42920436"><tt>Size_Type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link4" id="link4">Public Methods</a></h2>
-
- <h3><a name="link5" id="link5">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class=
-"c2"><tt>direct_mod_range_hashing</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link6" id="link6">Protected Methods</a></h2>
-
- <h3><a name="link7" id="link7">Notification Methods</a></h3>
-
- <h3><a name="link8" id="link8">Operators.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- <b>operator</b>()
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> hash) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Transforms the hash value <span class=
- "c1"><tt>hash</tt></span> into a ranged-hash value (using
- a modulo operation).</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/disclaimer.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/disclaimer.html
deleted file mode 100644
index 681af4edf..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/disclaimer.html
+++ /dev/null
@@ -1,34 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>What, me worry?</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h2>Disclaimer and Copyright</h2>
-
- <p>Revised 16 February, 2004</p>&copy; Copyright Ami Tavory and
- Vladimir Dreizin, IBM-HRL, 2004, and Benjamin Kosnik, Red Hat,
- 2004.
-
- <p>Permission to use, copy, modify, sell, and distribute this
- software is hereby granted without fee, provided that the above
- copyright notice appears in all copies, and that both that
- copyright notice and this permission notice appear in
- supporting documentation.</p>
-
- <p>None of the above authors, nor IBM Haifa Research
- Laboratories, Red Hat, or both, make any representation about
- the suitability of this software for any purpose. It is
- provided "as is" without express or implied warranty.</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ds_gen.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ds_gen.html
deleted file mode 100644
index ec99c4d5f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ds_gen.html
+++ /dev/null
@@ -1,344 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Data-Structure Genericity</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Data-Structure Genericity</h1>
-
- <h2><a name="problem" id="problem">The Basic Problem</a></h2>
-
- <p>The design attempts to address the following problem. When
- writing a function manipulating a generic container object,
- what is the behavior of the object? <i>E.g.</i>, suppose one
- writes</p>
- <pre>
-<b>template</b>&lt;<b>typename</b> Cntnr&gt;
-<b>void</b>
-some_op_sequence(Cntnr &amp;r_container)
-{
- ...
-}
-</pre>then one needs to address the following questions in the body
-of <tt>some_op_sequence</tt>:
-
- <ol>
- <li>Which types and methods does <tt>Cntnr</tt> support?
- Containers based on hash tables can be queries for the
- hash-functor type and object; this is meaningless for
- tree-based containers. Containers based on trees can be
- split, joined, or can erase iterators and return the
- following iterator; this cannot be done by hash-based
- containers.</li>
-
- <li>What are the guarantees of <tt>Cntnr</tt>? A container
- based on a probing hash-table invalidates all iterators when
- it is modified; this is not the case for containers based on
- node-based trees. Containers based on a node-based tree can
- be split or joined without exceptions; this is not the case
- for containers based on vector-based trees.</li>
-
- <li>How does the container maintain its elements? Tree-based
- and Trie-based containers store elements by key order;
- others, typically, do not. A container based on a splay trees
- or lists with update policies "cache" "frequently accessed"
- elements; containers based on most other underlying
- data structures do not.</li>
- </ol>
-
- <p>The remainder of this section deals with these issues.</p>
-
- <h2><a name="ds_hierarchy" id="ds_hierarchy">Container
- Hierarchy</a></h2>
-
- <p>Figure <a href="#cd">Container class hierarchy</a> shows the
- container hierarchy.</p>
-
- <h6 class="c1"><a name="cd" id="cd"><img src="container_cd.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Container class hierarchy.</h6>
-
- <ol>
- <li><a href=
- "container_base.html"><tt>container_base</tt></a> is an
- abstract base class for associative containers.</li>
-
- <li>Tree-Like-Based Associative-Containers:
-
- <ol>
- <li><a href=
- "basic_tree.html"><tt>basic_tree</tt></a>
- is an abstract base class for tree-like-based
- associative-containers</li>
-
- <li><a href=
- "tree.html"><tt>tree</tt></a>
- is a concrete base class for tree-based
- associative-containers</li>
-
- <li><a href=
- "trie.html"><tt>trie</tt></a>
- is a concrete base class trie-based
- associative-containers</li>
- </ol>
- </li>
-
- <li>Hash-Based Associative-Containers:
-
- <ol>
- <li><a href=
- "basic_hash_table.html"><tt>basic_hash_table</tt></a>
- is an abstract base class for hash-based
- associative-containers</li>
-
- <li><a href=
- "cc_hash_table.html"><tt>cc_hash_table</tt></a>
- is a concrete collision-chaining hash-based
- associative-containers</li>
-
- <li><a href=
- "gp_hash_table.html"><tt>gp_hash_table</tt></a>
- is a concrete (general) probing hash-based
- associative-containers</li>
- </ol>
- </li>
-
- <li>List-Based Associative-Containers:
-
- <ol>
- <li><a href=
- "list_update.html"><tt>list_update</tt></a> -
- list-based update-policy associative container</li>
- </ol>
- </li>
- </ol>
-
- <p>The hierarchy is composed naturally so that commonality is
- captured by base classes. Thus <tt><b>operator[]</b></tt> is
- defined <a href=
- "container_base.html"><tt>container_base</tt></a>, since
- all containers support it. Conversely <tt>split</tt> is defined
- in <a href=
- "basic_tree.html"><tt>basic_tree</tt></a>,
- since only tree-like containers support it. <a href=
- "#container_traits">Data-Structure Tags and Traits</a> discusses how
- to query which types and methods each container supports.</p>
-
- <h2><a name="container_traits" id="container_traits">Data-Structure Tags and
- Traits</a></h2>
-
- <p>Tags and traits are very useful for manipulating generic
- types. For example, if <tt>It</tt> is an iterator class, then
- <tt><b>typename</b> It::iterator_category</tt> or
- <tt><b>typename</b>
- std::iterator_traits&lt;It&gt;::iterator_category</tt> will
- yield its category, and <tt><b>typename</b>
- std::iterator_traits&lt;It&gt;::value_type</tt> will yield its
- value type.</p>
-
- <p><tt>pb_ds</tt> contains a tag hierarchy corresponding to the
- hierarchy in Figure <a href="#cd">Class hierarchy</a>. The tag
- hierarchy is shown in Figure <a href=
- "#tag_cd">Data-structure tag class hierarchy</a>.</p>
-
- <h6 class="c1"><a name="tag_cd" id="tag_cd"><img src=
- "assoc_container_tag_cd.png" alt="no image" /></a></h6>
-
- <h6 class="c1">Data-structure tag class hierarchy.</h6>
-
- <p><a href=
- "container_base.html"><tt>container_base</tt></a>
- publicly defines <tt>container_category</tt> as one of the classes in
- Figure <a href="#tag_cd">Data-structure tag class
- hierarchy</a>. Given any container <tt>Cntnr</tt>, the tag of
- the underlying data structure can be found via
- <tt><b>typename</b> Cntnr::container_category</tt>.</p>
-
- <p>Additionally, a traits mechanism can be used to query a
- container type for its attributes. Given any container
- <tt>Cntnr</tt>, then <tt><a href=
- "assoc_container_traits.html">__gnu_pbds::container_traits</a>&lt;Cntnr&gt;</tt>
- is a traits class identifying the properties of the
- container.</p>
-
- <p>To find if a container can throw when a key is erased (which
- is true for vector-based trees, for example), one can
- use</p><a href=
- "assoc_container_traits.html"><tt>container_traits</tt></a><tt>&lt;Cntnr&gt;::erase_can_throw</tt>,
- for example.
-
- <p>Some of the definitions in <a href=
- "assoc_container_traits.html"><tt>container_traits</tt></a> are
- dependent on other definitions. <i>E.g.</i>, if <a href=
- "assoc_container_traits.html"><tt>container_traits</tt></a><tt>&lt;Cntnr&gt;::order_preserving</tt>
- is <tt><b>true</b></tt> (which is the case for containers based
- on trees and tries), then the container can be split or joined;
- in this case, <a href=
- "assoc_container_traits.html"><tt>container_traits</tt></a><tt>&lt;Cntnr&gt;::split_join_can_throw</tt>
- indicates whether splits or joins can throw exceptions (which
- is true for vector-based trees); otherwise <a href=
- "assoc_container_traits.html"><tt>container_traits</tt></a><tt>&lt;Cntnr&gt;::split_join_can_throw</tt>
- will yield a compilation error. (This is somewhat similar to a
- compile-time version of the COM model [<a href=
- "references.html#mscom">mscom</a>]).</p>
-
- <h2><a name="find_range" id="find_range">Point-Type and
- Range-Type Methods and Iterators</a></h2>
-
- <h3><a name="it_unordered" id="it_unordered">Iterators in
- Unordered Container Types</a></h3>
-
- <p><tt>pb_ds</tt> differentiates between two types of methods
- and iterators: point-type methods and iterators, and range-type
- methods and iterators (see <a href=
- "motivation.html#assoc_diff_it">Motivation::Associative
- Containers::Differentiating between Iterator Types</a> and
- <a href="tutorial.html#assoc_find_range">Tutorial::Associative
- Containers::Point-Type and Range-Type Methods and
- Iterators</a>). Each associative container's interface includes
- the methods:</p>
- <pre>
-const_point_iterator
-find(const_key_reference r_key) const;
-
-point_iterator
-find(const_key_reference r_key);
-
-std::pair&lt;point_iterator,<b>bool</b>&gt;
-insert(const_reference r_val);
-</pre>
-
- <p>The relationship between these iterator types varies between
- container types. Figure <a href=
- "#point_iterators_cd">Point-type and range-type iterators</a>-A
- shows the most general invariant between point-type and
- range-type iterators: <tt>iterator</tt>, <i>e.g.</i>, can
- always be converted to <tt>point_iterator</tt>. Figure <a href=
- "#point_iterators_cd">Point-type and range-type iterators</a>-B
- shows invariants for order-preserving containers: point-type
- iterators are synonymous with range-type iterators.
- Orthogonally, Figure <a href="#point_iterators_cd">Point-type
- and range-type iterators</a>-C shows invariants for "set"
- containers: iterators are synonymous with const iterators.</p>
-
- <h6 class="c1"><a name="point_iterators_cd" id=
- "point_iterators_cd"><img src="point_iterators_cd.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Point-type and range-type iterators.</h6>
-
- <p>Note that point-type iterators in self-organizing containers
- (<i>e.g.</i>, hash-based associative containers) lack movement
- operators, such as <tt><b>operator++</b></tt> - in fact, this
- is the reason why <tt>pb_ds</tt> differentiates from the STL's
- design on this point.</p>
-
- <p>Typically, one can determine an iterator's movement
- capabilities in the STL using
- <tt>std::iterator_traits&lt;It&gt;iterator_category</tt>, which
- is a <tt><b>struct</b></tt> indicating the iterator's movement
- capabilities. Unfortunately, none of the STL's predefined
- categories reflect a pointer's <u>not</u> having any movement
- capabilities whatsoever. Consequently, <tt>pb_ds</tt> adds a
- type <a href=
- "trivial_iterator_tag.html"><tt>trivial_iterator_tag</tt></a>
- (whose name is taken from a concept in [<a href=
- "references.html#sgi_stl">sgi_stl</a>]), which is the category
- of iterators with no movement capabilities. All other STL tags,
- such as <tt>forward_iterator_tag</tt> retain their common
- use.</p>
-
- <h3><a name="inv_guar" id="inv_guar">Invalidation
- Guarantees</a></h3>
-
- <p><a href=
- "motivation.html#assoc_inv_guar">Motivation::Associative
- Containers::Differentiating between Iterator
- Types::Invalidation Guarantees</a> posed a problem. Given three
- different types of associative containers, a modifying
- operation (in that example, <tt>erase</tt>) invalidated
- iterators in three different ways: the iterator of one
- container remained completely valid - it could be de-referenced
- and incremented; the iterator of a different container could
- not even be de-referenced; the iterator of the third container
- could be de-referenced, but its "next" iterator changed
- unpredictably.</p>
-
- <p>Distinguishing between find and range types allows
- fine-grained invalidation guarantees, because these questions
- correspond exactly to the question of whether point-type
- iterators and range-type iterators are valid. <a href=
- "#invalidation_guarantee_cd">Invalidation guarantees class
- hierarchy</a> shows tags corresponding to different types of
- invalidation guarantees.</p>
-
- <h6 class="c1"><a name="invalidation_guarantee_cd" id=
- "invalidation_guarantee_cd"><img src=
- "invalidation_guarantee_cd.png" alt="no image" /></a></h6>
-
- <h6 class="c1">Invalidation guarantees class hierarchy.</h6>
-
- <ol>
- <li><a href=
- "basic_invalidation_guarantee.html"><tt>basic_invalidation_guarantee</tt></a>
- corresponds to a basic guarantee that a point-type iterator,
- a found pointer, or a found reference, remains valid as long
- as the container object is not modified.</li>
-
- <li><a href=
- "point_invalidation_guarantee.html"><tt>point_invalidation_guarantee</tt></a>
- corresponds to a guarantee that a point-type iterator, a
- found pointer, or a found reference, remains valid even if
- the container object is modified.</li>
-
- <li><a href=
- "range_invalidation_guarantee.html"><tt>range_invalidation_guarantee</tt></a>
- corresponds to a guarantee that a range-type iterator remains
- valid even if the container object is modified.</li>
- </ol>
-
- <p>As shown in <a href=
- "tutorial.html#assoc_find_range">Tutorial::Associative
- Containers::Point-Type and Range-Type Methods and
- Iterators</a>, to find the invalidation guarantee of a
- container, one can use</p>
- <pre>
-<b>typename</b> <a href=
-"assoc_container_traits.html">container_traits</a>&lt;Cntnr&gt;::invalidation_guarantee
-</pre>
-
- <p>which is one of the classes in Figure <a href=
- "#invalidation_guarantee_cd">Invalidation guarantees class
- hierarchy</a>.</p>
-
- <p>Note that this hierarchy corresponds to the logic it
- represents: if a container has range-invalidation guarantees,
- then it must also have find invalidation guarantees;
- correspondingly, its invalidation guarantee (in this case
- <a href=
- "range_invalidation_guarantee.html"><tt>range_invalidation_guarantee</tt></a>)
- can be cast to its base class (in this case <a href=
- "point_invalidation_guarantee.html"><tt>point_invalidation_guarantee</tt></a>).
- This means that this this hierarchy can be used easily using
- standard metaprogramming techniques, by specializing on the
- type of <tt>invalidation_guarantee</tt>.</p>
-
- <p>(These types of problems were addressed, in a more general
- setting, in [<a href=
- "references.html#meyers96more">meyers96more</a>] - Item 2. In
- our opinion, an invalidation-guarantee hierarchy would solve
- these problems in all container types - not just associative
- containers.)</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_1.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_1.png
deleted file mode 100644
index 9470a65b5..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_1.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_2.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_2.png
deleted file mode 100644
index d2ac91c1a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_2.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_3.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_3.png
deleted file mode 100644
index 08ecb0ffe..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/embedded_lists_3.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/examples.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/examples.html
deleted file mode 100644
index 03c7a3910..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/examples.html
+++ /dev/null
@@ -1,24 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Examples</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Examples</h1>
-
- <p><a href="assoc_examples.html">Associative-Container
- Examples</a> shows examples for associative containers;
- <a href="pq_examples.html">Priority-Queue Examples</a> shows
- examples for priority queues.</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/exceptions.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/exceptions.html
deleted file mode 100644
index a51e8ebe0..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/exceptions.html
+++ /dev/null
@@ -1,46 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
-<title>container_error Interface</title>
-<meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
-</head>
-
-<body>
-<div id="page">
-<h1><tt>container_error</tt> Interface</h1>
-
-<p>Base class for associative-container exceptions.</p>
-
-<p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/exception.hpp"><tt>exception.hpp</tt></a></p>
-
-<h2><a name="link1" id="link1">Base Classes</a></h2>
-
-<table class="c1" width="100%" border="1" summary="Bases">
-<tr>
-<td width="80%" align="left"><b>Class</b></td>
-
-<td width="20%" align="left"><b>Derivation Type</b></td>
-</tr>
-
-<tr>
-<td>
-<pre>
-std::logic_error
-</pre>
-</td>
-
-<td>
-<p>public</p>
-</td>
-</tr>
-</table>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_gcc.png
deleted file mode 100644
index d86299b7e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_local.png
deleted file mode 100644
index 1b31b7f27..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_msvc.png
deleted file mode 100644
index b7082f286..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_find_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_gcc.png
deleted file mode 100644
index b9fbe00de..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_local.png
deleted file mode 100644
index c693ed386..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_msvc.png
deleted file mode 100644
index 248ff6b88..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_find_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_gcc.png
deleted file mode 100644
index ac4f838fe..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_local.png
deleted file mode 100644
index 9fa08a0c2..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_msvc.png
deleted file mode 100644
index 5f1d740b8..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_random_int_subscript_timing_test_insert_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_table.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_table.html
deleted file mode 100644
index dd9d725d3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_table.html
+++ /dev/null
@@ -1,891 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>gp_hash_table Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>gp_hash_table</tt> Interface</h1>
-
- <p>A concrete general-probing hash-based associative
- container.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Key2501" id="Key2501"><b>typename</b> Key</a>
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a>
-</pre>
- </td>
-
- <td>
- <p>Mapped type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Hash_Fn1515835" id=
-"Hash_Fn1515835"><b>class</b> Hash_Fn </a>
-</pre>
- </td>
-
- <td>
- <p>Hash functor.</p>
- </td>
-
- <td>
- <pre>
-__gnu_cxx::hash&lt;<a href="#Key2501"><tt>Key</tt></a>&gt;
-</pre>if using gcc;
- <pre>
-stdext::hash_value&lt;<a href="#Key2501"><tt>Key</tt></a>&gt;
-</pre>if using Visual C++ .net
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Eq_Fn60085" id="Eq_Fn60085"><b>class</b> Eq_Fn </a>
-</pre>
- </td>
-
- <td>
- <p>Equivalence functor.</p>
- </td>
-
- <td>
- <pre>
-std::equal_to&lt;<a href="#Key2501"><tt>Key</tt></a>&gt;
-</pre>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Comb_Probe_Fn1603930855" id=
-"Comb_Probe_Fn1603930855"><b>class</b> Comb_Probe_Fn </a>
-</pre>
- </td>
-
- <td>
- <p>Combining probe functor.</p>
-
- <p>If <a href="#Hash_Fn1515835"><tt>Hash_Fn</tt></a> is
- <a href="null_hash_fn.html"><span class=
- "c2"><tt>null_hash_fn</tt></span></a>, and <a href=
- "#Probe_Fn8454835"><tt>Probe_Fn</tt></a> is <a href=
- "null_probe_fn.html"><span class=
- "c2"><tt>null_probe_fn</tt></span></a>, then this is the
- ranged-probe functor; otherwise, this is the
- range-hashing functor.</p>
-
- <p>(See <a href=
- "hash_based_containers.html#hash_policies">Design::Hash-Based
- Containers::Hash Policies</a>.)</p>
- </td>
-
- <td><a href="direct_mask_range_hashing.html"><span class=
- "c2"><tt>direct_mask_range_hashing</tt></span></a></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Probe_Fn8454835" id=
-"Probe_Fn8454835"><b>class</b> Probe_Fn </a>
-</pre>
- </td>
-
- <td>
- <p>Probe functor.</p>
- </td>
-
- <td>
- If <tt><a href=
- "#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a></tt>
- is <a href="direct_mask_range_hashing.html"><span class=
- "c2"><tt>direct_mask_range_hashing</tt></span></a>, then
- <pre>
-<a href="linear_probe_fn.html"><span class=
-"c2"><tt>linear_probe_fn</tt></span></a>&lt;
- <b>typename</b> <a href=
-"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type&gt;
-</pre>otherwise,
- <pre>
-<a href="quadratic_probe_fn.html"><span class=
-"c2"><tt>quadratic_probe_fn</tt></span></a>&lt;
- <b>typename</b> <a href=
-"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type&gt;
-</pre>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Resize_Policy566860465" id=
-"Resize_Policy566860465"><b>class</b> Resize_Policy </a>
-</pre>
- </td>
-
- <td>
- <p>Resize policy.</p>
- </td>
-
- <td>
- If <tt><a href=
- "#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a></tt>
- is <tt><a href=
- "direct_mask_range_hashing.html"><span class=
- "c2"><tt>direct_mask_range_hashing</tt></span></a></tt>,
- then
- <pre>
-<a href="hash_standard_resize_policy.html"><span class=
-"c2"><tt>hash_standard_resize_policy</tt></span></a>&lt;
- <a href="hash_exponential_size_policy.html"><span class=
-"c2"><tt>hash_exponential_size_policy</tt></span></a>&lt;
- <b>typename</b> <a href=
-"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type&gt;,
- <a href="hash_load_check_resize_trigger.html"><span class=
-"c2"><tt>hash_load_check_resize_trigger</tt></span></a>&lt;
- <b>typename</b> <a href=
-"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type&gt;,
- <b>false</b>,
- <b>typename</b> <a href=
-"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type&gt;
-</pre>otherwise,
- <pre>
-<a href="hash_standard_resize_policy.html"><span class=
-"c2"><tt>hash_standard_resize_policy</tt></span></a>&lt;
- <a href="hash_exponential_size_policy.html"><span class=
-"c2"><tt>hash_exponential_size_policy</tt></span></a>&lt;
- <b>typename</b> <a href=
-"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type&gt;,
- <a href="hash_load_check_resize_trigger.html"><span class=
-"c2"><tt>hash_load_check_resize_trigger</tt></span></a>&lt;
- <b>typename</b> <a href=
-"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type&gt;,
- <b>false</b>,
- <b>typename</b> <a href=
-"#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>::size_type&gt;
-</pre>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Store_Hash218262104" id=
-"Store_Hash218262104"><b>bool</b> Store_Hash </a>
-</pre>
- </td>
-
- <td>
- <p>Indicates whether the hash value will be stored along
- with each key.</p>
-
- <p>If <tt><a href=
- "#hash_fn2015995"><tt>hash_fn</tt></a></tt> is <a href=
- "null_hash_fn.html"><span class=
- "c2"><tt>null_hash_fn</tt></span></a>, then the container
- will not compile if this value is
- <tt><b>true</b></tt></p>
- </td>
-
- <td>
- <pre>
-<tt><b>false</b></tt>
-</pre>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator </a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>
- <pre>
-std::allocator&lt;<b>char</b>&gt;
-</pre>
- </td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="basic_hash_table.html"><span class=
-"c2"><tt>basic_hash_table</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Types and
- Constants</a></h2>
-
- <h3><a name="link4" id="link4">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="hash_fn2015995" id="hash_fn2015995">hash_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Hash_Fn1515835"><tt>Hash_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Hash functor type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="eq_fn80245" id="eq_fn80245">eq_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Eq_Fn60085"><tt>Eq_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Equivalence functor type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="comb_probe_fn828996423" id=
-"comb_probe_fn828996423">comb_probe_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Comb_Probe_Fn1603930855"><tt>Comb_Probe_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Combining probe functor type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="probe_fn10954995" id="probe_fn10954995">probe_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Probe_Fn8454835"><tt>Probe_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Probe functor type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="resize_policy4084493169" id=
-"resize_policy4084493169">resize_policy</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Resize_Policy566860465"><tt>Resize_Policy</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Resize policy type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Public Methods</a></h2>
-
- <h3><a name="link6" id="link6">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- gp_hash_table
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- gp_hash_table
- (<b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking some policy objects. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- gp_hash_table
- (<b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking some policy objects. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, and <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- gp_hash_table
- (<b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn,
- <b>const</b> <a href=
-"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &amp;r_comb_probe_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking some policy objects. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object, and <span class=
- "c1"><tt>r_comb_probe_fn</tt></span> will be copied by
- the <a href=
- "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a>
- object of the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- gp_hash_table
- (<b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn,
- <b>const</b> <a href=
-"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &amp;r_comb_probe_fn,
- <b>const</b> <a href=
-"#probe_fn10954995"><tt>probe_fn</tt></a> &amp;r_probe_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking some policy objects. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object, <span class=
- "c1"><tt>r_comb_probe_fn</tt></span> will be copied by
- the <a href=
- "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a>
- object of the container object, and <span class=
- "c1"><tt>r_probe_fn</tt></span> will be copied by the
- <a href="#probe_fn10954995"><tt>probe_fn</tt></a> object
- of the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- gp_hash_table
- (<b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn,
- <b>const</b> <a href=
-"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &amp;r_comb_probe_fn,
- <b>const</b> <a href=
-"#probe_fn10954995"><tt>probe_fn</tt></a> &amp;r_probe_fn,
- <b>const</b> <a href=
-"#resize_policy4084493169"><tt>resize_policy</tt></a> &amp;r_resize_policy)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking some policy objects. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object, <span class=
- "c1"><tt>r_comb_probe_fn</tt></span> will be copied by
- the <a href=
- "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a>
- object of the container object, <span class=
- "c1"><tt>r_probe_fn</tt></span> will be copied by the
- <a href="#probe_fn10954995"><tt>probe_fn</tt></a> object
- of the container object, and <span class=
- "c1"><tt>r_resize_policy</tt></span> will be copied by
- the <a href=
- "#Resize_Policy566860465"><tt>Resize_Policy</tt></a>
- object of the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- gp_hash_table
- (It first_it,
- It last_it)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of
- value_types. The value_types between <span class=
- "c1"><tt>first_it</tt></span> and <span class=
- "c1"><tt>last_it</tt></span> will be inserted into the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- gp_hash_table
- (It first_it,
- It last_it,
- <b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of value_types
- and some policy objects. The value_types between
- <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- gp_hash_table
- (It first_it,
- It last_it,
- <b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of value_types
- and some policy objects. The value_types between
- <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, and <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- gp_hash_table
- (It first_it,
- It last_it,
- <b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn,
- <b>const</b> <a href=
-"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &amp;r_comb_probe_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of value_types
- and some policy objects. The value_types between
- <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object, and <span class=
- "c1"><tt>r_comb_probe_fn</tt></span> will be copied by
- the <a href=
- "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a>
- object of the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- gp_hash_table
- (It first_it,
- It last_it,
- <b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn,
- <b>const</b> <a href=
-"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &amp;r_comb_probe_fn,
- <b>const</b> <a href=
-"#probe_fn10954995"><tt>probe_fn</tt></a> &amp;r_probe_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of value_types
- and some policy objects. The value_types between
- <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object, <span class=
- "c1"><tt>r_comb_probe_fn</tt></span> will be copied by
- the <a href=
- "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a>
- object of the container object, and <span class=
- "c1"><tt>r_probe_fn</tt></span> will be copied by the
- <a href="#probe_fn10954995"><tt>probe_fn</tt></a> object
- of the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- gp_hash_table
- (It first_it,
- It last_it,
- <b>const</b> <a href=
-"#hash_fn2015995"><tt>hash_fn</tt></a> &amp;r_hash_fn,
- <b>const</b> <a href=
-"#eq_fn80245"><tt>eq_fn</tt></a> &amp;r_eq_fn,
- <b>const</b> <a href=
-"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &amp;r_comb_probe_fn,
- <b>const</b> <a href=
-"#probe_fn10954995"><tt>probe_fn</tt></a> &amp;r_probe_fn,
- <b>const</b> <a href=
-"#resize_policy4084493169"><tt>resize_policy</tt></a> &amp;r_resize_policy)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of value_types
- and some policy objects. The value_types between
- <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object. <span class=
- "c1"><tt>r_hash_fn</tt></span> will be copied by the
- <a href="#hash_fn2015995"><tt>hash_fn</tt></a> object of
- the container object, <span class=
- "c1"><tt>r_eq_fn</tt></span> will be copied by the
- <a href="#eq_fn80245"><tt>eq_fn</tt></a> object of the
- container object, <span class=
- "c1"><tt>r_comb_probe_fn</tt></span> will be copied by
- the <a href=
- "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a>
- object of the container object, <span class=
- "c1"><tt>r_probe_fn</tt></span> will be copied by the
- <a href="#probe_fn10954995"><tt>probe_fn</tt></a> object
- of the container object, and <span class=
- "c1"><tt>r_resize_policy</tt></span> will be copied by
- the <a href=
- "#resize_policy4084493169"><tt>resize_policy</tt></a>
- object of the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- gp_hash_table
- (<b>const</b> <span class=
-"c2"><tt>gp_hash_table</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b>
- ~gp_hash_table
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<span class="c2"><tt>gp_hash_table</tt></span> &amp;
- <b>operator</b>=
- (<b>const</b> <span class=
-"c2"><tt>gp_hash_table</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Assignment operator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class=
-"c2"><tt>gp_hash_table</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Policy Access Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &amp;
- get_comb_probe_fn
- ()
-</pre>
- </td>
-
- <td>
- <p>Access to the <a href=
- "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a>
- object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>const</b> <a href=
-"#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a> &amp;
- get_comb_probe_fn
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Const access to the <a href=
- "#comb_probe_fn828996423"><tt>comb_probe_fn</tt></a>
- object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#probe_fn10954995"><tt>probe_fn</tt></a> &amp;
- get_probe_fn
- ()
-</pre>
- </td>
-
- <td>
- <p>Access to the <a href=
- "#probe_fn10954995"><tt>probe_fn</tt></a> object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>const</b> <a href=
-"#probe_fn10954995"><tt>probe_fn</tt></a> &amp;
- get_probe_fn
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Const access to the <a href=
- "#probe_fn10954995"><tt>probe_fn</tt></a> object.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_tag.html
deleted file mode 100644
index 4c5f06b57..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/gp_hash_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>gp_hash_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>gp_hash_tag</tt> Interface</h1>
-
- <p>General-probing hash data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="basic_hash_tag.html"><span class=
-"c2"><tt>basic_hash_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_based_containers.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_based_containers.html
deleted file mode 100644
index 21d092a76..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_based_containers.html
+++ /dev/null
@@ -1,835 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Hash-Based Containers</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Hash Table Design</h1>
-
- <h2><a name="overview" id="overview">Overview</a></h2>
-
- <p>The collision-chaining hash-based container has the
- following declaration.</p>
- <pre>
-<b>template</b>&lt;
- <b>typename</b> Key,
- <b>typename</b> Mapped,
- <b>typename</b> Hash_Fn = std::hash&lt;Key&gt;,
- <b>typename</b> Eq_Fn = std::equal_to&lt;Key&gt;,
- <b>typename</b> Comb_Hash_Fn = <a href=
-"direct_mask_range_hashing.html">direct_mask_range_hashing</a>&lt;&gt;
- <b>typename</b> Resize_Policy = <i>default explained below.</i>
- <b>bool</b> Store_Hash = <b>false</b>,
- <b>typename</b> Allocator = std::allocator&lt;<b>char</b>&gt; &gt;
-<b>class</b> <a href=
-"cc_hash_table.html">cc_hash_table</a>;
-</pre>
-
- <p>The parameters have the following meaning:</p>
-
- <ol>
- <li><tt>Key</tt> is the key type.</li>
-
- <li><tt>Mapped</tt> is the mapped-policy, and is explained in
- <a href="tutorial.html#assoc_ms">Tutorial::Associative
- Containers::Associative Containers Others than Maps</a>.</li>
-
- <li><tt>Hash_Fn</tt> is a key hashing functor.</li>
-
- <li><tt>Eq_Fn</tt> is a key equivalence functor.</li>
-
- <li><tt>Comb_Hash_Fn</tt> is a <i>range-hashing_functor</i>;
- it describes how to translate hash values into positions
- within the table. This is described in <a href=
- "#hash_policies">Hash Policies</a>.</li>
-
- <li><tt>Resize_Policy</tt> describes how a container object
- should change its internal size. This is described in
- <a href="#resize_policies">Resize Policies</a>.</li>
-
- <li><tt>Store_Hash</tt> indicates whether the hash value
- should be stored with each entry. This is described in
- <a href="#policy_interaction">Policy Interaction</a>.</li>
-
- <li><tt>Allocator</tt> is an allocator
- type.</li>
- </ol>
-
- <p>The probing hash-based container has the following
- declaration.</p>
- <pre>
-<b>template</b>&lt;
- <b>typename</b> Key,
- <b>typename</b> Mapped,
- <b>typename</b> Hash_Fn = std::hash&lt;Key&gt;,
- <b>typename</b> Eq_Fn = std::equal_to&lt;Key&gt;,
- <b>typename</b> Comb_Probe_Fn = <a href=
-"direct_mask_range_hashing.html">direct_mask_range_hashing</a>&lt;&gt;
- <b>typename</b> Probe_Fn = <i>default explained below.</i>
- <b>typename</b> Resize_Policy = <i>default explained below.</i>
- <b>bool</b> Store_Hash = <b>false</b>,
- <b>typename</b> Allocator = std::allocator&lt;<b>char</b>&gt; &gt;
-<b>class</b> <a href=
-"gp_hash_table.html">gp_hash_table</a>;
-</pre>
-
- <p>The parameters are identical to those of the
- collision-chaining container, except for the following.</p>
-
- <ol>
- <li><tt>Comb_Probe_Fn</tt> describes how to transform a probe
- sequence into a sequence of positions within the table.</li>
-
- <li><tt>Probe_Fn</tt> describes a probe sequence policy.</li>
- </ol>
-
- <p>Some of the default template values depend on the values of
- other parameters, and are explained in <a href=
- "#policy_interaction">Policy Interaction</a>.</p>
-
- <h2><a name="hash_policies" id="hash_policies">Hash
- Policies</a></h2>
-
- <h3><a name="general_terms" id="general_terms">General
- Terms</a></h3>
-
- <p>Following is an explanation of some functions which hashing
- involves. Figure <a href=
- "#hash_ranged_hash_range_hashing_fns">Hash functions,
- ranged-hash functions, and range-hashing functions</a>)
- illustrates the discussion.</p>
-
- <h6 class="c1"><a name="hash_ranged_hash_range_hashing_fns" id=
- "hash_ranged_hash_range_hashing_fns"><img src=
- "hash_ranged_hash_range_hashing_fns.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Hash functions, ranged-hash functions, and
- range-hashing functions.</h6>
-
- <p>Let <i>U</i> be a domain (<i>e.g.</i>, the integers, or the
- strings of 3 characters). A hash-table algorithm needs to map
- elements of <i>U</i> "uniformly" into the range <i>[0,..., m -
- 1]</i> (where <i>m</i> is a non-negative integral value, and
- is, in general, time varying). <i>I.e.</i>, the algorithm needs
- a <i>ranged-hash</i> function</p>
-
- <p><i>f : U &times; Z<sub>+</sub> &rarr; Z<sub>+</sub></i>
- ,</p>
-
- <p>such that for any <i>u</i> in <i>U</i> ,</p>
-
- <p><i>0 &le; f(u, m) &le; m - 1</i> ,</p>
-
- <p>and which has "good uniformity" properties [<a href=
- "references.html#knuth98sorting">knuth98sorting</a>]. One
- common solution is to use the composition of the hash
- function</p>
-
- <p><i>h : U &rarr; Z<sub>+</sub></i> ,</p>
-
- <p>which maps elements of <i>U</i> into the non-negative
- integrals, and</p>
-
- <p class="c2">g : Z<sub>+</sub> &times; Z<sub>+</sub> &rarr;
- Z<sub>+</sub>,</p>
-
- <p>which maps a non-negative hash value, and a non-negative
- range upper-bound into a non-negative integral in the range
- between 0 (inclusive) and the range upper bound (exclusive),
- <i>i.e.</i>, for any <i>r</i> in <i>Z<sub>+</sub></i>,</p>
-
- <p><i>0 &le; g(r, m) &le; m - 1</i> .</p>
-
- <p>The resulting ranged-hash function, is</p>
-
- <p><i><a name="ranged_hash_composed_of_hash_and_range_hashing"
- id="ranged_hash_composed_of_hash_and_range_hashing">f(u , m) =
- g(h(u), m)</a></i> (1) .</p>
-
- <p>From the above, it is obvious that given <i>g</i> and
- <i>h</i>, <i>f</i> can always be composed (however the converse
- is not true). The STL's hash-based containers allow specifying
- a hash function, and use a hard-wired range-hashing function;
- the ranged-hash function is implicitly composed.</p>
-
- <p>The above describes the case where a key is to be mapped
- into a <i>single position</i> within a hash table, <i>e.g.</i>,
- in a collision-chaining table. In other cases, a key is to be
- mapped into a <i>sequence of positions</i> within a table,
- <i>e.g.</i>, in a probing table. Similar terms apply in this
- case: the table requires a <i>ranged probe</i> function,
- mapping a key into a sequence of positions withing the table.
- This is typically achieved by composing a <i>hash function</i>
- mapping the key into a non-negative integral type, a
- <i>probe</i> function transforming the hash value into a
- sequence of hash values, and a <i>range-hashing</i> function
- transforming the sequence of hash values into a sequence of
- positions.</p>
-
- <h3><a name="range_hashing_fns" id=
- "range_hashing_fns">Range-Hashing Functions</a></h3>
-
- <p>Some common choices for range-hashing functions are the
- division, multiplication, and middle-square methods [<a href=
- "references.html#knuth98sorting">knuth98sorting</a>], defined
- as</p>
-
- <p><i><a name="division_method" id="division_method">g(r, m) =
- r mod m</a></i> (2) ,</p>
-
- <p><i>g(r, m) = &lceil; u/v ( a r mod v ) &rceil;</i> ,</p>
-
- <p>and</p>
-
- <p><i>g(r, m) = &lceil; u/v ( r<sup>2</sup> mod v ) &rceil;</i>
- ,</p>
-
- <p>respectively, for some positive integrals <i>u</i> and
- <i>v</i> (typically powers of 2), and some <i>a</i>. Each of
- these range-hashing functions works best for some different
- setting.</p>
-
- <p>The division method <a href="#division_method">(2)</a> is a
- very common choice. However, even this single method can be
- implemented in two very different ways. It is possible to
- implement <a href="#division_method">(2)</a> using the low
- level <i>%</i> (modulo) operation (for any <i>m</i>), or the
- low level <i>&amp;</i> (bit-mask) operation (for the case where
- <i>m</i> is a power of 2), <i>i.e.</i>,</p>
-
- <p><i><a name="division_method_prime_mod" id=
- "division_method_prime_mod">g(r, m) = r % m</a></i> (3) ,</p>
-
- <p>and</p>
-
- <p><i><a name="division_method_bit_mask" id=
- "division_method_bit_mask">g(r, m) = r &amp; m - 1, (m =
- 2<sup>k</sup>)</a></i> for some <i>k)</i> (4),</p>
-
- <p>respectively.</p>
-
- <p>The <i>%</i> (modulo) implementation <a href=
- "#division_method_prime_mod">(3)</a> has the advantage that for
- <i>m</i> a prime far from a power of 2, <i>g(r, m)</i> is
- affected by all the bits of <i>r</i> (minimizing the chance of
- collision). It has the disadvantage of using the costly modulo
- operation. This method is hard-wired into SGI's implementation
- [<a href="references.html#sgi_stl">sgi_stl</a>].</p>
-
- <p>The <i>&amp;</i> (bit-mask) implementation <a href=
- "#division_method_bit_mask">(4)</a> has the advantage of
- relying on the fast bit-wise and operation. It has the
- disadvantage that for <i>g(r, m)</i> is affected only by the
- low order bits of <i>r</i>. This method is hard-wired into
- Dinkumware's implementation [<a href=
- "references.html#dinkumware_stl">dinkumware_stl</a>].</p>
-
- <h3><a name="hash_policies_ranged_hash_policies" id=
- "hash_policies_ranged_hash_policies">Ranged-Hash
- Functions</a></h3>
-
- <p>In cases it is beneficial to allow the
- client to directly specify a ranged-hash hash function. It is
- true, that the writer of the ranged-hash function cannot rely
- on the values of <i>m</i> having specific numerical properties
- suitable for hashing (in the sense used in [<a href=
- "references.html#knuth98sorting">knuth98sorting</a>]), since
- the values of <i>m</i> are determined by a resize policy with
- possibly orthogonal considerations.</p>
-
- <p>There are two cases where a ranged-hash function can be
- superior. The firs is when using perfect hashing [<a href=
- "references.html#knuth98sorting">knuth98sorting</a>]; the
- second is when the values of <i>m</i> can be used to estimate
- the "general" number of distinct values required. This is
- described in the following.</p>
-
- <p>Let</p>
-
- <p class="c2">s = [ s<sub>0</sub>,..., s<sub>t - 1</sub>]</p>
-
- <p>be a string of <i>t</i> characters, each of which is from
- domain <i>S</i>. Consider the following ranged-hash
- function:</p>
-
- <p><a name="total_string_dna_hash" id=
- "total_string_dna_hash"><i>f<sub>1</sub>(s, m) = &sum; <sub>i =
- 0</sub><sup>t - 1</sup> s<sub>i</sub> a<sup>i</sup></i> mod
- <i>m</i></a> (5) ,</p>
-
- <p>where <i>a</i> is some non-negative integral value. This is
- the standard string-hashing function used in SGI's
- implementation (with <i>a = 5</i>) [<a href=
- "references.html#sgi_stl">sgi_stl</a>]. Its advantage is that
- it takes into account all of the characters of the string.</p>
-
- <p>Now assume that <i>s</i> is the string representation of a
- of a long DNA sequence (and so <i>S = {'A', 'C', 'G',
- 'T'}</i>). In this case, scanning the entire string might be
- prohibitively expensive. A possible alternative might be to use
- only the first <i>k</i> characters of the string, where</p>
-
- <p>|S|<sup>k</sup> &ge; m ,</p>
-
- <p><i>i.e.</i>, using the hash function</p>
-
- <p><a name="only_k_string_dna_hash" id=
- "only_k_string_dna_hash"><i>f<sub>2</sub>(s, m) = &sum; <sub>i
- = 0</sub><sup>k - 1</sup> s<sub>i</sub> a<sup>i</sup></i> mod
- <i>m</i></a> , (6)</p>
-
- <p>requiring scanning over only</p>
-
- <p><i>k =</i> log<i><sub>4</sub>( m )</i></p>
-
- <p>characters.</p>
-
- <p>Other more elaborate hash-functions might scan <i>k</i>
- characters starting at a random position (determined at each
- resize), or scanning <i>k</i> random positions (determined at
- each resize), <i>i.e.</i>, using</p>
-
- <p><i>f<sub>3</sub>(s, m) = &sum; <sub>i =
- r</sub>0</i><sup>r<sub>0</sub> + k - 1</sup> s<sub>i</sub>
- a<sup>i</sup> mod <i>m</i> ,</p>
-
- <p>or</p>
-
- <p><i>f<sub>4</sub>(s, m) = &sum; <sub>i = 0</sub><sup>k -
- 1</sup> s<sub>r</sub>i</i> a<sup>r<sub>i</sub></sup> mod
- <i>m</i> ,</p>
-
- <p>respectively, for <i>r<sub>0</sub>,..., r<sub>k-1</sub></i>
- each in the (inclusive) range <i>[0,...,t-1]</i>.</p>
-
- <p>It should be noted that the above functions cannot be
- decomposed as <a href=
- "#ranged_hash_composed_of_hash_and_range_hashing">(1)</a> .</p>
-
- <h3><a name="pb_ds_imp" id="pb_ds_imp">Implementation</a></h3>
-
- <p>This sub-subsection describes the implementation of the
- above in <tt>pb_ds</tt>. It first explains range-hashing
- functions in collision-chaining tables, then ranged-hash
- functions in collision-chaining tables, then probing-based
- tables, and, finally, lists the relevant classes in
- <tt>pb_ds</tt>.</p>
-
- <h4>Range-Hashing and Ranged-Hashes in Collision-Chaining
- Tables</h4>
-
- <p><a href=
- "cc_hash_table.html"><tt>cc_hash_table</tt></a> is
- parametrized by <tt>Hash_Fn</tt> and <tt>Comb_Hash_Fn</tt>, a
- hash functor and a combining hash functor, respectively.</p>
-
- <p>In general, <tt>Comb_Hash_Fn</tt> is considered a
- range-hashing functor. <a href=
- "cc_hash_table.html"><tt>cc_hash_table</tt></a>
- synthesizes a ranged-hash function from <tt>Hash_Fn</tt> and
- <tt>Comb_Hash_Fn</tt> (see <a href=
- "#ranged_hash_composed_of_hash_and_range_hashing">(1)</a>
- above). Figure <a href="#hash_range_hashing_seq_diagram">Insert
- hash sequence diagram</a> shows an <tt>insert</tt> sequence
- diagram for this case. The user inserts an element (point A),
- the container transforms the key into a non-negative integral
- using the hash functor (points B and C), and transforms the
- result into a position using the combining functor (points D
- and E).</p>
-
- <h6 class="c1"><a name="hash_range_hashing_seq_diagram" id=
- "hash_range_hashing_seq_diagram"><img src=
- "hash_range_hashing_seq_diagram.png" alt="no image" /></a></h6>
-
- <h6 class="c1">Insert hash sequence diagram.</h6>
-
- <p>If <a href=
- "cc_hash_table.html"><tt>cc_hash_table</tt></a>'s
- hash-functor, <tt>Hash_Fn</tt> is instantiated by <a href=
- "null_hash_fn.html"><tt>null_hash_fn</tt></a> (see <a href=
- "concepts.html#concepts_null_policies">Interface::Concepts::Null
- Policy Classes</a>), then <tt>Comb_Hash_Fn</tt> is taken to be
- a ranged-hash function. Figure <a href=
- "#hash_range_hashing_seq_diagram2">Insert hash sequence diagram
- with a null hash policy</a> shows an <tt>insert</tt> sequence
- diagram. The user inserts an element (point A), the container
- transforms the key into a position using the combining functor
- (points B and C).</p>
-
- <h6 class="c1"><a name="hash_range_hashing_seq_diagram2" id=
- "hash_range_hashing_seq_diagram2"><img src=
- "hash_range_hashing_seq_diagram2.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Insert hash sequence diagram with a null hash
- policy.</h6>
-
- <h4>Probing Tables</h4>
-
- <p><a href=
- "gp_hash_table.html"></a><tt>gp_hash_table</tt> is
- parametrized by <tt>Hash_Fn</tt>, <tt>Probe_Fn</tt>, and
- <tt>Comb_Probe_Fn</tt>. As before, if <tt>Hash_Fn</tt> and
- <tt>Probe_Fn</tt> are, respectively, <a href=
- "null_hash_fn.html"><tt>null_hash_fn</tt></a> and <a href=
- "null_probe_fn.html"><tt>null_probe_fn</tt></a>, then
- <tt>Comb_Probe_Fn</tt> is a ranged-probe functor. Otherwise,
- <tt>Hash_Fn</tt> is a hash functor, <tt>Probe_Fn</tt> is a
- functor for offsets from a hash value, and
- <tt>Comb_Probe_Fn</tt> transforms a probe sequence into a
- sequence of positions within the table.</p>
-
- <h4>Pre-Defined Policies</h4>
-
- <p><tt>pb_ds</tt> contains some pre-defined classes
- implementing range-hashing and probing functions:</p>
-
- <ol>
- <li><a href=
- "direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
- and <a href=
- "direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
- are range-hashing functions based on a bit-mask and a modulo
- operation, respectively.</li>
-
- <li><a href=
- "linear_probe_fn.html"><tt>linear_probe_fn</tt></a>, and
- <a href=
- "quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a> are
- a linear probe and a quadratic probe function,
- respectively.</li>
- </ol>Figure <a href="#hash_policy_cd">Hash policy class
- diagram</a> shows a class diagram.
-
- <h6 class="c1"><a name="hash_policy_cd" id=
- "hash_policy_cd"><img src="hash_policy_cd.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Hash policy class diagram.</h6>
-
- <h2><a name="resize_policies" id="resize_policies">Resize
- Policies</a></h2>
-
- <h3><a name="general" id="general">General Terms</a></h3>
-
- <p>Hash-tables, as opposed to trees, do not naturally grow or
- shrink. It is necessary to specify policies to determine how
- and when a hash table should change its size. Usually, resize
- policies can be decomposed into orthogonal policies:</p>
-
- <ol>
- <li>A <i>size policy</i> indicating <i>how</i> a hash table
- should grow (<i>e.g.,</i> it should multiply by powers of
- 2).</li>
-
- <li>A <i>trigger policy</i> indicating <i>when</i> a hash
- table should grow (<i>e.g.,</i> a load factor is
- exceeded).</li>
- </ol>
-
- <h3><a name="size_policies" id="size_policies">Size
- Policies</a></h3>
-
- <p>Size policies determine how a hash table changes size. These
- policies are simple, and there are relatively few sensible
- options. An exponential-size policy (with the initial size and
- growth factors both powers of 2) works well with a mask-based
- range-hashing function (see <a href=
- "#hash_policies">Range-Hashing Policies</a>), and is the
- hard-wired policy used by Dinkumware [<a href=
- "references.html#dinkumware_stl">dinkumware_stl</a>]. A
- prime-list based policy works well with a modulo-prime range
- hashing function (see <a href="#hash_policies">Range-Hashing
- Policies</a>), and is the hard-wired policy used by SGI's
- implementation [<a href=
- "references.html#sgi_stl">sgi_stl</a>].</p>
-
- <h3><a name="trigger_policies" id="trigger_policies">Trigger
- Policies</a></h3>
-
- <p>Trigger policies determine when a hash table changes size.
- Following is a description of two policies: <i>load-check</i>
- policies, and collision-check policies.</p>
-
- <p>Load-check policies are straightforward. The user specifies
- two factors, <i>&alpha;<sub>min</sub></i> and
- <i>&alpha;<sub>max</sub></i>, and the hash table maintains the
- invariant that</p>
-
- <p><i><a name="load_factor_min_max" id=
- "load_factor_min_max">&alpha;<sub>min</sub> &le; (number of
- stored elements) / (hash-table size) &le;
- &alpha;<sub>max</sub></a></i> (1) .</p>
-
- <p>Collision-check policies work in the opposite direction of
- load-check policies. They focus on keeping the number of
- collisions moderate and hoping that the size of the table will
- not grow very large, instead of keeping a moderate load-factor
- and hoping that the number of collisions will be small. A
- maximal collision-check policy resizes when the longest
- probe-sequence grows too large.</p>
-
- <p>Consider Figure <a href="#balls_and_bins">Balls and
- bins</a>. Let the size of the hash table be denoted by
- <i>m</i>, the length of a probe sequence be denoted by
- <i>k</i>, and some load factor be denoted by &alpha;. We would
- like to calculate the minimal length of <i>k</i>, such that if
- there were <i>&alpha; m</i> elements in the hash table, a probe
- sequence of length <i>k</i> would be found with probability at
- most <i>1/m</i>.</p>
-
- <h6 class="c1"><a name="balls_and_bins" id=
- "balls_and_bins"><img src="balls_and_bins.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Balls and bins.</h6>
-
- <p>Denote the probability that a probe sequence of length
- <i>k</i> appears in bin <i>i</i> by <i>p<sub>i</sub></i>, the
- length of the probe sequence of bin <i>i</i> by
- <i>l<sub>i</sub></i>, and assume uniform distribution. Then</p>
-
- <p><a name="prob_of_p1" id=
- "prob_of_p1"><i>p<sub>1</sub></i></a> = (3)</p>
-
- <p class="c2"><b>P</b>(l<sub>1</sub> &ge; k) =</p>
-
- <p><i><b>P</b>(l<sub>1</sub> &ge; &alpha; ( 1 + k / &alpha; - 1
- ) &le;</i> (a)</p>
-
- <p><i>e ^ ( - ( &alpha; ( k / &alpha; - 1 )<sup>2</sup> ) /2
- )</i> ,</p>
-
- <p>where (a) follows from the Chernoff bound [<a href=
- "references.html#motwani95random">motwani95random</a>]. To
- calculate the probability that <i>some</i> bin contains a probe
- sequence greater than <i>k</i>, we note that the
- <i>l<sub>i</sub></i> are negatively-dependent [<a href=
- "references.html#dubhashi98neg">dubhashi98neg</a>]. Let
- <i><b>I</b>(.)</i> denote the indicator function. Then</p>
-
- <p><a name="at_least_k_i_n_some_bin" id=
- "at_least_k_i_n_some_bin"><i><b>P</b>( exists<sub>i</sub>
- l<sub>i</sub> &ge; k ) =</i> (3)</a></p>
-
- <p class="c2"><b>P</b> ( &sum; <sub>i = 1</sub><sup>m</sup>
- <b>I</b>(l<sub>i</sub> &ge; k) &ge; 1 ) =</p>
-
- <p><i><b>P</b> ( &sum; <sub>i = 1</sub><sup>m</sup> <b>I</b> (
- l<sub>i</sub> &ge; k ) &ge; m p<sub>1</sub> ( 1 + 1 / (m
- p<sub>1</sub>) - 1 ) ) &le;</i> (a)</p>
-
- <p class="c2">e ^ ( ( - m p<sub>1</sub> ( 1 / (m p<sub>1</sub>)
- - 1 ) <sup>2</sup> ) / 2 ) ,</p>
-
- <p>where (a) follows from the fact that the Chernoff bound can
- be applied to negatively-dependent variables [<a href=
- "references.html#dubhashi98neg">dubhashi98neg</a>]. Inserting
- <a href="#prob_of_p1">(2)</a> into <a href=
- "#at_least_k_i_n_some_bin">(3)</a>, and equating with
- <i>1/m</i>, we obtain</p>
-
- <p><i>k ~ &radic; ( 2 &alpha;</i> ln <i>2 m</i> ln<i>(m) )
- )</i> .</p>
-
- <h3><a name="imp_pb_ds" id="imp_pb_ds">Implementation</a></h3>
-
- <p>This sub-subsection describes the implementation of the
- above in <tt>pb_ds</tt>. It first describes resize policies and
- their decomposition into trigger and size policies, then
- describes pre-defined classes, and finally discusses controlled
- access the policies' internals.</p>
-
- <h4>Resize Policies and Their Decomposition</h4>
-
- <p>Each hash-based container is parametrized by a
- <tt>Resize_Policy</tt> parameter; the container derives
- <tt><b>public</b></tt>ly from <tt>Resize_Policy</tt>. For
- example:</p>
- <pre>
-<a href="cc_hash_table.html">cc_hash_table</a>&lt;
- <b>typename</b> Key,
- <b>typename</b> Mapped,
- ...
- <b>typename</b> Resize_Policy
- ...&gt; :
- <b>public</b> Resize_Policy
-</pre>
-
- <p>As a container object is modified, it continuously notifies
- its <tt>Resize_Policy</tt> base of internal changes
- (<i>e.g.</i>, collisions encountered and elements being
- inserted). It queries its <tt>Resize_Policy</tt> base whether
- it needs to be resized, and if so, to what size.</p>
-
- <p>Figure <a href="#insert_resize_sequence_diagram1">Insert
- resize sequence diagram</a> shows a (possible) sequence diagram
- of an insert operation. The user inserts an element; the hash
- table notifies its resize policy that a search has started
- (point A); in this case, a single collision is encountered -
- the table notifies its resize policy of this (point B); the
- container finally notifies its resize policy that the search
- has ended (point C); it then queries its resize policy whether
- a resize is needed, and if so, what is the new size (points D
- to G); following the resize, it notifies the policy that a
- resize has completed (point H); finally, the element is
- inserted, and the policy notified (point I).</p>
-
- <h6 class="c1"><a name="insert_resize_sequence_diagram1" id=
- "insert_resize_sequence_diagram1"><img src=
- "insert_resize_sequence_diagram1.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Insert resize sequence diagram.</h6>
-
- <p>In practice, a resize policy can be usually orthogonally
- decomposed to a size policy and a trigger policy. Consequently,
- the library contains a single class for instantiating a resize
- policy: <a href=
- "hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- is parametrized by <tt>Size_Policy</tt> and
- <tt>Trigger_Policy</tt>, derives <tt><b>public</b></tt>ly from
- both, and acts as a standard delegate [<a href=
- "references.html#gamma95designpatterns">gamma95designpatterns</a>]
- to these policies.</p>
-
- <p>Figures <a href="#insert_resize_sequence_diagram2">Standard
- resize policy trigger sequence diagram</a> and <a href=
- "#insert_resize_sequence_diagram3">Standard resize policy size
- sequence diagram</a> show sequence diagrams illustrating the
- interaction between the standard resize policy and its trigger
- and size policies, respectively.</p>
-
- <h6 class="c1"><a name="insert_resize_sequence_diagram2" id=
- "insert_resize_sequence_diagram2"><img src=
- "insert_resize_sequence_diagram2.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Standard resize policy trigger sequence
- diagram.</h6>
-
- <h6 class="c1"><a name="insert_resize_sequence_diagram3" id=
- "insert_resize_sequence_diagram3"><img src=
- "insert_resize_sequence_diagram3.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Standard resize policy size sequence
- diagram.</h6>
-
- <h4>Pre-Defined Policies</h4>
-
- <p>The library includes the following
- instantiations of size and trigger policies:</p>
-
- <ol>
- <li><a href=
- "hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- implements a load check trigger policy.</li>
-
- <li><a href=
- "cc_hash_max_collision_check_resize_trigger.html"><tt>cc_hash_max_collision_check_resize_trigger</tt></a>
- implements a collision check trigger policy.</li>
-
- <li><a href=
- "hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
- implements an exponential-size policy (which should be used
- with mask range hashing).</li>
-
- <li><a href=
- "hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
- implementing a size policy based on a sequence of primes
- [<a href="references.html#sgi_stl">sgi_stl</a>] (which should
- be used with mod range hashing</li>
- </ol>
-
- <p>Figure <a href="#resize_policy_cd">Resize policy class
- diagram</a> gives an overall picture of the resize-related
- classes. <a href=
- "basic_hash_table.html"><tt>basic_hash_table</tt></a>
- is parametrized by <tt>Resize_Policy</tt>, which it subclasses
- publicly. This class is currently instantiated only by <a href=
- "hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>.
- <a href=
- "hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- itself is parametrized by <tt>Trigger_Policy</tt> and
- <tt>Size_Policy</tt>. Currently, <tt>Trigger_Policy</tt> is
- instantiated by <a href=
- "hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>,
- or <a href=
- "cc_hash_max_collision_check_resize_trigger.html"><tt>cc_hash_max_collision_check_resize_trigger</tt></a>;
- <tt>Size_Policy</tt> is instantiated by <a href=
- "hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>,
- or <a href=
- "hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>.</p>
-
- <h6 class="c1"><a name="resize_policy_cd" id=
- "resize_policy_cd"><img src="resize_policy_cd.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Resize policy class diagram.</h6>
-
- <h4>Controlled Access to Policies' Internals</h4>
-
- <p>There are cases where (controlled) access to resize
- policies' internals is beneficial. <i>E.g.</i>, it is sometimes
- useful to query a hash-table for the table's actual size (as
- opposed to its <tt>size()</tt> - the number of values it
- currently holds); it is sometimes useful to set a table's
- initial size, externally resize it, or change load factors.</p>
-
- <p>Clearly, supporting such methods both decreases the
- encapsulation of hash-based containers, and increases the
- diversity between different associative-containers' interfaces.
- Conversely, omitting such methods can decrease containers'
- flexibility.</p>
-
- <p>In order to avoid, to the extent possible, the above
- conflict, the hash-based containers themselves do not address
- any of these questions; this is deferred to the resize policies,
- which are easier to change or replace. Thus, for example,
- neither <a href=
- "cc_hash_table.html"><tt>cc_hash_table</tt></a> nor
- <a href=
- "gp_hash_table.html"><tt>gp_hash_table</tt></a>
- contain methods for querying the actual size of the table; this
- is deferred to <a href=
- "hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>.</p>
-
- <p>Furthermore, the policies themselves are parametrized by
- template arguments that determine the methods they support
- ([<a href=
- "references.html#alexandrescu01modern">alexandrescu01modern</a>]
- shows techniques for doing so). <a href=
- "hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- is parametrized by <tt>External_Size_Access</tt> that
- determines whether it supports methods for querying the actual
- size of the table or resizing it. <a href=
- "hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- is parametrized by <tt>External_Load_Access</tt> that
- determines whether it supports methods for querying or
- modifying the loads. <a href=
- "cc_hash_max_collision_check_resize_trigger.html"><tt>cc_hash_max_collision_check_resize_trigger</tt></a>
- is parametrized by <tt>External_Load_Access</tt> that
- determines whether it supports methods for querying the
- load.</p>
-
- <p>Some operations, for example, resizing a container at
- run time, or changing the load factors of a load-check trigger
- policy, require the container itself to resize. As mentioned
- above, the hash-based containers themselves do not contain
- these types of methods, only their resize policies.
- Consequently, there must be some mechanism for a resize policy
- to manipulate the hash-based container. As the hash-based
- container is a subclass of the resize policy, this is done
- through virtual methods. Each hash-based container has a
- <tt><b>private</b></tt> <tt><b>virtual</b></tt> method:</p>
- <pre>
-<b>virtual void</b>
- do_resize
- (size_type new_size);
-</pre>
-
- <p>which resizes the container. Implementations of
- <tt>Resize_Policy</tt> can export public methods for resizing
- the container externally; these methods internally call
- <tt>do_resize</tt> to resize the table.</p>
-
- <h2><a name="policy_interaction" id="policy_interaction">Policy
- Interaction</a></h2>
-
- <p>Hash-tables are unfortunately especially susceptible to
- choice of policies. One of the more complicated aspects of this
- is that poor combinations of good policies can form a poor
- container. Following are some considerations.</p>
-
- <h3><a name="policy_interaction_probe_size_trigger" id=
- "policy_interaction_probe_size_trigger">Probe Policies, Size
- Policies, and Trigger Policies</a></h3>
-
- <p>Some combinations do not work well for probing containers.
- For example, combining a quadratic probe policy with an
- exponential size policy can yield a poor container: when an
- element is inserted, a trigger policy might decide that there
- is no need to resize, as the table still contains unused
- entries; the probe sequence, however, might never reach any of
- the unused entries.</p>
-
- <p>Unfortunately, <tt>pb_ds</tt> cannot detect such problems at
- compilation (they are halting reducible). It therefore defines
- an exception class <a href=
- "insert_error.html"><tt>insert_error</tt></a> to throw an
- exception in this case.</p>
-
- <h3><a name="policy_interaction_hash_trigger" id=
- "policy_interaction_hash_trigger">Hash Policies and Trigger
- Policies</a></h3>
-
- <p>Some trigger policies are especially susceptible to poor
- hash functions. Suppose, as an extreme case, that the hash
- function transforms each key to the same hash value. After some
- inserts, a collision detecting policy will always indicate that
- the container needs to grow.</p>
-
- <p>The library, therefore, by design, limits each operation to
- one resize. For each <tt>insert</tt>, for example, it queries
- only once whether a resize is needed.</p>
-
- <h3><a name="policy_interaction_eq_sth_hash" id=
- "policy_interaction_eq_sth_hash">Equivalence Functors, Storing
- Hash Values, and Hash Functions</a></h3>
-
- <p><a href=
- "cc_hash_table.html"><tt>cc_hash_table</tt></a> and
- <a href=
- "gp_hash_table.html"><tt>gp_hash_table</tt></a> are
- parametrized by an equivalence functor and by a
- <tt>Store_Hash</tt> parameter. If the latter parameter is
- <tt><b>true</b></tt>, then the container stores with each entry
- a hash value, and uses this value in case of collisions to
- determine whether to apply a hash value. This can lower the
- cost of collision for some types, but increase the cost of
- collisions for other types.</p>
-
- <p>If a ranged-hash function or ranged probe function is
- directly supplied, however, then it makes no sense to store the
- hash value with each entry. <tt>pb_ds</tt>'s container will
- fail at compilation, by design, if this is attempted.</p>
-
- <h3><a name="policy_interaction_size_load_check" id=
- "policy_interaction_size_load_check">Size Policies and
- Load-Check Trigger Policies</a></h3>
-
- <p>Assume a size policy issues an increasing sequence of sizes
- <i>a, a q, a q<sup>1</sup>, a q<sup>2</sup>, ...</i> For
- example, an exponential size policy might issue the sequence of
- sizes <i>8, 16, 32, 64, ...</i></p>
-
- <p>If a load-check trigger policy is used, with loads
- <i>&alpha;<sub>min</sub></i> and <i>&alpha;<sub>max</sub></i>,
- respectively, then it is a good idea to have:</p>
-
- <ol>
- <li><i>&alpha;<sub>max</sub> ~ 1 / q</i></li>
-
- <li><i>&alpha;<sub>min</sub> &lt; 1 / (2 q)</i></li>
- </ol>
-
- <p>This will ensure that the amortized hash cost of each
- modifying operation is at most approximately 3.</p>
-
- <p><i>&alpha;<sub>min</sub> ~ &alpha;<sub>max</sub></i> is, in
- any case, a bad choice, and <i>&alpha;<sub>min</sub> &gt;
- &alpha;<sub>max</sub></i> is horrendous.</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_exponential_size_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_exponential_size_policy.html
deleted file mode 100644
index 1089b1544..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_exponential_size_policy.html
+++ /dev/null
@@ -1,183 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>hash_exponential_size_policy Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>hash_exponential_size_policy</tt> Interface</h1>
-
- <p>A size policy whose sequence of sizes form an exponential
- sequence (typically powers of 2)</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Size_Type42920436" id=
-"Size_Type42920436"><b>typename</b> Size_Type </a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
-
- <td>size_t</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Size_Type42920436"><tt>Size_Type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link4" id="link4">Public Methods</a></h2>
-
- <h3><a name="link5" id="link5">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- hash_exponential_size_policy
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> start_size = 8,
- <a href=
-"#size_type55424436"><tt>size_type</tt></a> grow_factor = 2)
-</pre>
- </td>
-
- <td>
- <p>Default constructor, or constructor taking a
- <span class="c1"><tt>start_size</tt></span>, or
- constructor taking a start size and <span class=
- "c1"><tt>grow_factor</tt></span>. The policy will use the
- sequence of sizes <span class=
- "c1"><tt>start_size</tt></span>, <span class=
- "c1"><tt>start_size</tt></span> * <span class=
- "c1"><tt>grow_factor</tt></span>, <span class=
- "c1"><tt>start_size</tt></span> * <span class=
- "c1"><tt>grow_factor</tt></span>^2, ...</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class=
-"c2"><tt>hash_exponential_size_policy</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link6" id="link6">Protected Methods</a></h2>
-
- <h3><a name="link7" id="link7">Size methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#size_type55424436"><tt>size_type</tt></a>
- get_nearest_larger_size
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> size) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Given a size <span class="c1"><tt>size</tt></span>,
- returns a size that is larger.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#size_type55424436"><tt>size_type</tt></a>
- get_nearest_smaller_size
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> size) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Given a size <span class="c1"><tt>size</tt></span>,
- returns a size that is smaller.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html
deleted file mode 100644
index b22b7b5cf..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_load_check_resize_trigger.html
+++ /dev/null
@@ -1,583 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>hash_load_check_resize_trigger Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>hash_load_check_resize_trigger</tt> Interface</h1>
-
- <p>A resize trigger policy based on a load check. It keeps the
- load factor between some load factors load_min and
- load_max.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="External_Load_Access1313998607" id=
-"External_Load_Access1313998607"><b>bool</b> External_Load_Access </a>
-</pre>
- </td>
-
- <td>
- <p>Specifies whether the load factor can be accessed
- externally. The two options have different trade-offs in
- terms of flexibility, genericity, and encapsulation.</p>
- </td>
-
- <td><tt><b>false</b></tt></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Size_Type42920436" id=
-"Size_Type42920436"><b>typename</b> Size_Type </a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
-
- <td>size_t</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Size_Type42920436"><tt>Size_Type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="external_load_access3976598639" id=
-"external_load_access3976598639">external_load_access</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"#External_Load_Access1313998607"><tt>External_Load_Access</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Indicates whether loads can be accessed externally</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link4" id="link4">Public Methods</a></h2>
-
- <h3><a name="link5" id="link5">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- hash_load_check_resize_trigger
- (float load_min = 0.125,
- float load_max = 0.5)
-</pre>
- </td>
-
- <td>
- <p>Default constructor, or constructor taking
- <span class="c1"><tt>load_min</tt></span> and
- <span class="c1"><tt>load_max</tt></span> load factors
- between which this policy will keep the actual load.</p>
-
- <p>It is the responsibility of the user to ensure that
- <span class="c1"><tt>load_min</tt></span> is smaller than
- <span class="c1"><tt>load_max</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class=
-"c2"><tt>hash_load_check_resize_trigger</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- <b>virtual</b>
- ~hash_load_check_resize_trigger
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link6" id="link6">Load Access Methods</a></h3>
-
- <p>These methods are only available if the external access
- parameter is set.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> std::pair&lt;float, float&gt;
- get_loads
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a pair of the minimal and maximal loads,
- respectively.</p>
-
- <p>Calling this method will not compile when <a href=
- "#External_Load_Access1313998607"><tt>External_Load_Access</tt></a>
- == <tt><b>false</b></tt>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- set_loads
- (std::pair&lt;float, float&gt; load_pair)
-</pre>
- </td>
-
- <td>
- <p>Sets the loads through a pair of the minimal and
- maximal loads, respectively.</p>
-
- <p>Calling this method resizes the container, and might
- throw an exception. It is the responsibility of the user
- to pass appropriate loads to this function. Calling this
- method will not compile when <a href=
- "#External_Load_Access1313998607"><tt>External_Load_Access</tt></a>
- == <tt><b>false</b></tt>.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link7" id="link7">Protected Methods</a></h2>
-
- <h3><a name="link8" id="link8">Insert Search
- Notifications.</a></h3>
-
- <p>Notifications called during an insert operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link9" id="link9">Find Search
- Notifications.</a></h3>
-
- <p>Notifications called during a find operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link10" id="link10">Erase Search
- Notifications.</a></h3>
-
- <p>Notifications called during an insert operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link11" id="link11">Content Change
- Notifications.</a></h3>
-
- <p>Notifications called when the content of the table changes
- in a way that can affect the resize policy.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_inserted
- (<a href="#size_type55424436"><tt>size_type</tt></a> num_entries)
-</pre>
- </td>
-
- <td>
- <p>Notifies an element was inserted. the total number of
- entries in the table is <span class=
- "c1"><tt>num_entries</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erased
- (<a href="#size_type55424436"><tt>size_type</tt></a> num_entries)
-</pre>
- </td>
-
- <td>
- <p>Notifies an element was erased.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_cleared
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was cleared.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link12" id="link12">Size Change
- Notifications.</a></h3>
-
- <p>Notifications called when the table changes size.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_resized
- (<a href="#size_type55424436"><tt>size_type</tt></a> new_size)
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was resized as a result of this
- object's signifying that a resize is needed.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_externally_resized
- (<a href="#size_type55424436"><tt>size_type</tt></a> new_size)
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was resized externally.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link13" id="link13">Queries</a></h3>
-
- <p>Called to query whether/how to resize.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- is_resize_needed
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Queries whether a resize is needed.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- is_grow_needed
- (<a href="#size_type55424436"><tt>size_type</tt></a> size,
- <a href=
-"#size_type55424436"><tt>size_type</tt></a> num_entries) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Queries whether a grow is needed.</p>
-
- <p>This method is called only if this object indicated
- resize is needed. The actual <span class=
- "c1"><tt>size</tt></span> of the table is <span class=
- "c1"><tt>size</tt></span>, and the number of entries in
- it is <span class="c1"><tt>num_entries</tt></span>.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link14" id="link14">Private Methods</a></h2>
-
- <h3><a name="link15" id="link15">Overrides</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <b>void</b>
- do_resize
- (<a href="#size_type55424436"><tt>size_type</tt></a> new_size)
-</pre>
- </td>
-
- <td>
- <p>Resizes to <span class=
- "c1"><tt>new_size</tt></span>.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_policy_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_policy_cd.png
deleted file mode 100644
index f3122a112..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_policy_cd.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_prime_size_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_prime_size_policy.html
deleted file mode 100644
index 8976767b4..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_prime_size_policy.html
+++ /dev/null
@@ -1,149 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>hash_prime_size_policy Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>hash_prime_size_policy</tt> Interface</h1>
-
- <p>A size policy whose sequence of sizes form a
- nearly-exponential sequence of primes.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Public Types and
- Constants</a></h2>
-
- <h3><a name="link2" id="link2">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-size_t
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Methods</a></h2>
-
- <h3><a name="link4" id="link4">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- hash_prime_size_policy
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> start_size = 8)
-</pre>
- </td>
-
- <td>
- <p>Default constructor, or constructor taking a
- <span class="c1"><tt>start_size</tt></span> The policy
- will use the sequence of sizes approximately <span class=
- "c1"><tt>start_size</tt></span>, <span class=
- "c1"><tt>start_size</tt></span> * 2, <span class=
- "c1"><tt>start_size</tt></span> * 2^2, ...</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- swap
- (<span class=
-"c2"><tt>hash_prime_size_policy</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Protected Methods</a></h2>
-
- <h3><a name="link6" id="link6">Size methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#size_type55424436"><tt>size_type</tt></a>
- get_nearest_larger_size
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> size) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Given a size <span class="c1"><tt>size</tt></span>,
- returns a size that is larger.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#size_type55424436"><tt>size_type</tt></a>
- get_nearest_smaller_size
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> size) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Given a size <span class="c1"><tt>size</tt></span>,
- returns a size that is smaller.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html
deleted file mode 100644
index 2867595b0..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test.html
+++ /dev/null
@@ -1,173 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Tree Text Locality of Reference Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Hash-Based Erase Memory-Use Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of uniform i.i.d. integer keys
- into a container, then erases all keys except one. It measures
- the final size of the container.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/hash_random_int_erase_mem_usage.cc"><tt>hash_random_int_erase_mem_usage.cc</tt></a>
- 2000 2000 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks how containers adjust internally as their
- logical size decreases (see <a href="motivation.html#assoc_ers_methods">Motivation::Associative
- Containers::Slightly Different Methods::Methods Related to
- Erase</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NHG">NHG</a>, <a href="#NHM">NHM</a> and
- <a href="#NHL">NHL</a> show the results for the native and
- collision-chaining types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a> and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NHG_res_div">
-<div id="NHG_gcc">
-<div id="NHG_hash_random_int_erase_mem_usage_test">
-<div id="NHG_assoc">
-<div id="NHG_Native_456_collision-chaing_456_and_probing_456_hash_random_int_erase_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="hash_random_int_erase_mem_usage_test_gcc.png" alt="no image" /></a></h6>NHG: Native, collision-chaing, and probing, hash random int erase test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_set_ncah-
-<tt>std::tr1::unordered_set</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li>
-<li>
-gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a>
-</li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHM_res_div">
-<div id="NHM_msvc">
-<div id="NHM_hash_random_int_erase_mem_usage_test">
-<div id="NHM_assoc">
-<div id="NHM_Native_456_collision-chaing_456_and_probing_456_hash_random_int_erase_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="hash_random_int_erase_mem_usage_test_msvc.png" alt="no image" /></a></h6>NHM: Native, collision-chaing, and probing, hash random int erase test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_set_ncah-
-<tt>stdext::hash_set</tt></li>
-<li>
-gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a>
-</li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHM_res_div">
-<div id="NHM_msvc">
-<div id="NHM_hash_random_int_erase_mem_usage_test">
-<div id="NHM_assoc">
-<div id="NHM_Native_456_collision-chaing_456_and_probing_456_hash_random_int_erase_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="hash_random_int_erase_mem_usage_test_msvc.png" alt="no image" /></a></h6>NHM: Native, collision-chaing, and probing, hash random int erase test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_set_ncah-
-<tt>stdext::hash_set</tt></li>
-<li>
-gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a>
-</li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHL_res_div">
-<div id="NHL_local">
-<div id="NHL_hash_random_int_erase_mem_usage_test">
-<div id="NHL_assoc">
-<div id="NHL_Native_456_collision-chaing_456_and_probing_456_hash_random_int_erase_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="hash_random_int_erase_mem_usage_test_local.png" alt="no image" /></a></h6>NHL: Native, collision-chaing, and probing, hash random int erase test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>STL hash-based containers act very differently than trees in
- this respect. When erasing numerous keys from an STL
- associative-container, the resulting memory user varies greatly
- depending on whether the container is tree-based or hash-based.
- As noted in <a href="motivation.html#assoc_methods">Motivation::Choice of
- Methods</a> , this is a fundamental consequence of the STL's
- associative containers' interface, it is not due to a specific
- implementation.</p>
-<p>(See <a href="priority_queue_text_pop_mem_usage_test.html">Priority Queue
- Text <tt>pop</tt> Memory Use Test</a> for a similar phenomenon
- regarding priority queues.)</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_gcc.png
deleted file mode 100644
index c552506a7..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_local.png
deleted file mode 100644
index dbd3ee9d3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_msvc.png
deleted file mode 100644
index 8c23d46da..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_erase_mem_usage_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html
deleted file mode 100644
index b6066e7cf..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_find_find_timing_test.html
+++ /dev/null
@@ -1,247 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Hash Random Int Find Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Hash-Based Random-Integer <tt>find</tt> Find Timing
- Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with uniform i.i.d.
- integer keys into a container, then performs a series of finds
- using <tt>find</tt>. It measures the average time
- for<tt>find</tt> as a function of the number of values
- inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/random_int_find_timing.cc"><tt>random_int_find_timing_test</tt></a>
- 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- hash-tables (see <a href="hash_based_containers.html">Design::Associative
- Containers::Associative Containers::Hash-Based Containers</a>),
- range-hashing functions, and trigger policies (see <a href="hash_based_containers.html#hash_policies">Design::Associative
- Containers::Hash-Based Containers::Hash Policies</a> and
- <a href="hash_based_containers.html#resize_policies">Design::Associative
- Containers::Hash-Based Containers::Resize Policies</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NCCG">NCCG</a>, <a href="#NCCM">NCCM</a>,
- and <a href="#NCCL">NCCL</a> show the results for the native
- and collision-chaining types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NGPG">NGPG</a>, <a href="#NGPM">NGPM</a>, and <a href="#NGPL">NGPL</a> show the results
- for the native and probing types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>
- respectively.</p>
-<div id="NCCG_res_div">
-<div id="NCCG_gcc">
-<div id="NCCG_cc_hash_random_int_find_timing_test">
-<div id="NCCG_assoc">
-<div id="NCCG_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCG" id="NCCG"><img src="cc_hash_random_int_find_timing_test_gcc.png" alt="no image" /></a></h6>NCCG: Native and collision-chaining hash random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_map_ncah-
-<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NCCM_res_div">
-<div id="NCCM_msvc">
-<div id="NCCM_cc_hash_random_int_find_timing_test">
-<div id="NCCM_assoc">
-<div id="NCCM_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCM" id="NCCM"><img src="cc_hash_random_int_find_timing_test_msvc.png" alt="no image" /></a></h6>NCCM: Native and collision-chaining hash random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-n_hash_map_ncah-
-<tt>stdext::hash_map</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NCCL_res_div">
-<div id="NCCL_local">
-<div id="NCCL_cc_hash_random_int_find_timing_test">
-<div id="NCCL_assoc">
-<div id="NCCL_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCL" id= "NCCL"><img src="cc_hash_random_int_find_timing_test_local.png" alt="no image" /></a></h6>NCCL: Native and collision-chaining hash random int find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NGPG_res_div">
-<div id="NGPG_gcc">
-<div id="NGPG_gp_hash_random_int_find_timing_test">
-<div id="NGPG_assoc">
-<div id="NGPG_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPG" id="NGPG"><img src="gp_hash_random_int_find_timing_test_gcc.png" alt="no image" /></a></h6>NGPG: Native and collision-chaining hash random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a>
-</li>
-<li>
-n_hash_map_ncah-
-<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li>
-<li>
-gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NGPM_res_div">
-<div id="NGPM_msvc">
-<div id="NGPM_gp_hash_random_int_find_timing_test">
-<div id="NGPM_assoc">
-<div id="NGPM_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPM" id="NGPM"><img src="gp_hash_random_int_find_timing_test_msvc.png" alt="no image" /></a></h6>NGPM: Native and collision-chaining hash random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a>
-</li>
-<li>
-n_hash_map_ncah-
-<tt>stdext::hash_map</tt></li>
-<li>
-gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NGPL_res_div">
-<div id="NGPL_local">
-<div id="NGPL_gp_hash_random_int_find_timing_test">
-<div id="NGPL_assoc">
-<div id="NGPL_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPL" id= "NGPL"><img src="gp_hash_random_int_find_timing_test_local.png" alt="no image" /></a></h6>NGPL: Native and collision-chaining hash random int find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>In this setting, the choice of underlying hash-table (see
- <a href="hash_based_containers.html">Design::Associative
- Containers::Hash-Based Containers</a> ) affects performance
- most, then the range-hashing scheme (See <a href="hash_based_containers.html#hash_policies">Design::Associative
- Containers::Hash-Based Containers::Hash Policies</a> ), and,
- only finally, other policies.</p>
-<p>When comparing Figures <a href="#NCCG">NCCG</a> and <a href="#NCCM">NCCM</a> to <a href="#NGPG">NGPG</a> and <a href="#NGPM">NGPM</a> , respectively, it is apparent that the
- probing containers are less efficient than the
- collision-chaining containers (both
- <tt>std::tr1::unordered_map</tt> and <tt>stdext::hash_map</tt>
- use collision-chaining) in this case.</p>
-<p>( <a href="hash_random_int_subscript_insert_timing_test.html">Hash-Based
- Random-Integer Subscript Insert Timing Test</a> shows a
- different case, where the situation is reversed; <a href="assoc_performance_tests.html#hash_based_types">Observations::Hash-Based
- Container Types</a> discusses some further considerations.)</p>
-<p>Within each type of hash-table, the range-hashing scheme
- affects performance more than other policies; <a href="hash_text_find_find_timing_test.html#observations">Hash-Based
- Text <tt>find</tt> Find Timing Test::Observations</a> discusses
- this. In Figures <a href="#NCCG">NCCG</a> , <a href="#NCCM">NCCM</a> , <a href="#NGPG">NGPG</a> , and <a href="#NGPM">NGPM</a> , it should be noted that
- <tt>std::tr1::unordered_map</tt> and <tt>stdext::hash_map</tt>
- are hard-wired currently to mod-based and mask-based schemes,
- respectively.</p>
-<p><a href="assoc_performance_tests.html#hash_based_types">Observations::Hash-Based
- Container Types</a> summarizes some observations on hash-based
- containers; <a href="assoc_performance_tests.html#hash_based_policies">Observations::Hash-Based
- Containers' Policies</a> summarizes some observations on
- hash-based containers' policies.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html
deleted file mode 100644
index 002516370..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_find_timing_test.html
+++ /dev/null
@@ -1,220 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Hash Random Int Subscript Find Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Hash-Based Random-Integer <tt><b>operator</b>[]</tt>
- FindTiming Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with uniform i.i.d.
- integer keys into a container, then performs a series of finds
- using <tt><b>operator</b>[]</tt>. It measures the average time
- for <tt><b>operator</b>[]</tt> as a function of the number of
- values inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/random_int_subscript_find_timing.cc"><tt>hash_random_int_subscript_find_timing_test</tt></a>
- 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- hash-tables (see <a href="hash_based_containers.html">Design::Hash-Based Containers</a>
- ), range-hashing functions, and trigger policies (see <a href="hash_based_containers.html#hash_policies">Design::Hash-Based
- Containers::Hash Policies</a> and <a href="hash_based_containers.html#resize_policies">Design::Hash-Based
- Containers::Resize Policies</a> ).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NCCG">NCCG</a>, <a href="#NCCM">NCCM</a>,
- and <a href="#NCCL">NCCL</a> show the results for the native
- and collision-chaining types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NGPG">NGPG</a>, <a href="#NGPM">NGPM</a>, and <a href="#NGPL">NGPL</a> show the results
- for the native and probing types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NCCG_res_div">
-<div id="NCCG_gcc">
-<div id="NCCG_cc_hash_random_int_subscript_timing_test_find">
-<div id="NCCG_assoc">
-<div id="NCCG_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt__b_operator_455b__455tt__457"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCG" id="NCCG"><img src="cc_hash_random_int_subscript_timing_test_find_gcc.png" alt="no image" /></a></h6>NCCG: Native and collision-chaining hash random int find timing test using <tt><b>operator</b></tt>[] - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_map_ncah-
-<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NCCM_res_div">
-<div id="NCCM_msvc">
-<div id="NCCM_cc_hash_random_int_subscript_timing_test_find">
-<div id="NCCM_assoc">
-<div id="NCCM_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt__b_operator_455b__455tt__457"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCM" id="NCCM"><img src="cc_hash_random_int_subscript_timing_test_find_msvc.png" alt="no image" /></a></h6>NCCM: Native and collision-chaining hash random int find timing test using <tt><b>operator</b></tt>[] - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-n_hash_map_ncah-
-<tt>stdext::hash_map</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NCCL_res_div">
-<div id="NCCL_local">
-<div id="NCCL_cc_hash_random_int_subscript_timing_test_find">
-<div id="NCCL_assoc">
-<div id="NCCL_Native_and_collision-chaining_hash_random_int_find_timing_test_using__tt__b_operator_455b__455tt__457"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCL" id= "NCCL"><img src="cc_hash_random_int_subscript_timing_test_find_local.png" alt="no image" /></a></h6>NCCL: Native and collision-chaining hash random int find timing test using <tt><b>operator</b></tt>[] - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NGPG_res_div">
-<div id="NGPG_gcc">
-<div id="NGPG_gp_hash_random_int_subscript_timing_test_find">
-<div id="NGPG_assoc">
-<div id="NGPG_Native_and_probing_hash_random_int_find_timing_test_using__tt__b_operator_455b__455tt__457"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPG" id="NGPG"><img src="gp_hash_random_int_subscript_timing_test_find_gcc.png" alt="no image" /></a></h6>NGPG: Native and probing hash random int find timing test using <tt><b>operator</b></tt>[] - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_map_ncah-
-<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li>
-<li>
-gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a>
-</li>
-<li>
-gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NGPM_res_div">
-<div id="NGPM_msvc">
-<div id="NGPM_gp_hash_random_int_subscript_timing_test_find">
-<div id="NGPM_assoc">
-<div id="NGPM_Native_and_probing_hash_random_int_find_timing_test_using__tt__b_operator_455b__455tt__457"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPM" id="NGPM"><img src="gp_hash_random_int_subscript_timing_test_find_msvc.png" alt="no image" /></a></h6>NGPM: Native and probing hash random int find timing test using <tt><b>operator</b></tt>[] - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a>
-</li>
-<li>
-n_hash_map_ncah-
-<tt>stdext::hash_map</tt></li>
-<li>
-gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NGPL_res_div">
-<div id="NGPL_local">
-<div id="NGPL_gp_hash_random_int_subscript_timing_test_find">
-<div id="NGPL_assoc">
-<div id="NGPL_Native_and_probing_hash_random_int_find_timing_test_using__tt__b_operator_455b__455tt__457"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPL" id= "NGPL"><img src="gp_hash_random_int_subscript_timing_test_find_local.png" alt="no image" /></a></h6>NGPL: Native and probing hash random int find timing test using <tt><b>operator</b></tt>[] - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>This test shows similar results to <a href="hash_random_int_find_find_timing_test.html">Hash-Based
- Random-Integer <tt>find</tt> Find Timing Test</a> .</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html
deleted file mode 100644
index a15d03ba4..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_random_int_subscript_insert_timing_test.html
+++ /dev/null
@@ -1,365 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Hash Random Int Subscript Insert Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Hash-Based Random-Integer <tt><b>operator</b>[]</tt> Insert
- Timing Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with uniform i.i.d.
- integer keys into a container, using
- <tt><b>operator</b>[]</tt>. It measures the average time for
- <tt><b>operator</b>[]</tt> as a function of the number of
- values inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/random_int_subscript_insert_timing.cc"><tt>hash_random_int_subscript_insert_timing_test</tt></a>
- 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test primarily checks the effect of different underlying
- hash-tables (see <a href="hash_based_containers.html">Design::Associative
- Containers::Associative Containers::Hash-Based
- Containers</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NCCG">NCCG</a>, <a href="#NCCM">NCCM</a>,
- and <a href="#NCCL">NCCL</a> show the results for the native
- and collision-chaining types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NGPG">NGPG</a>, <a href="#NGPM">NGPM</a>, and <a href="#NGPL">NGPL</a> show the results
- for the native and probing types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>
- respectively; Figures <a href="#CCGPG">CCGPG</a>, <a href="#CCGPM">CCGPM</a>, and <a href="#CCGPL">CCGPL</a> compare the
- results for the collision-chaining and probing types of
- <tt>pb_ds</tt> only, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>
- respectively.</p>
-<div id="NCCG_res_div">
-<div id="NCCG_gcc">
-<div id="NCCG_cc_hash_random_int_subscript_timing_test_insert">
-<div id="NCCG_assoc">
-<div id="NCCG_Native_and_collision-chaining_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCG" id="NCCG"><img src="cc_hash_random_int_subscript_timing_test_insert_gcc.png" alt="no image" /></a></h6>NCCG: Native and collision-chaining hash random int insert timing test using <tt><b>operator</b></tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-n_hash_map_ncah-
-<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NCCM_res_div">
-<div id="NCCM_msvc">
-<div id="NCCM_cc_hash_random_int_subscript_timing_test_insert">
-<div id="NCCM_assoc">
-<div id="NCCM_Native_and_collision-chaining_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCM" id="NCCM"><img src="cc_hash_random_int_subscript_timing_test_insert_msvc.png" alt="no image" /></a></h6>NCCM: Native and collision-chaining hash random int insert timing test using <tt><b>operator</b></tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_map_ncah-
-<tt>stdext::hash_map</tt></li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NCCL_res_div">
-<div id="NCCL_local">
-<div id="NCCL_cc_hash_random_int_subscript_timing_test_insert">
-<div id="NCCL_assoc">
-<div id="NCCL_Native_and_collision-chaining_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCL" id= "NCCL"><img src="cc_hash_random_int_subscript_timing_test_insert_local.png" alt="no image" /></a></h6>NCCL: Native and collision-chaining hash random int insert timing test using <tt><b>operator</b></tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NGPG_res_div">
-<div id="NGPG_gcc">
-<div id="NGPG_gp_hash_random_int_subscript_timing_test_insert">
-<div id="NGPG_assoc">
-<div id="NGPG_Native_and_probing_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPG" id="NGPG"><img src="gp_hash_random_int_subscript_timing_test_insert_gcc.png" alt="no image" /></a></h6>NGPG: Native and probing hash random int insert timing test using <tt><b>operator</b></tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a>
-</li>
-<li>
-n_hash_map_ncah-
-<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li>
-<li>
-gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NGPM_res_div">
-<div id="NGPM_msvc">
-<div id="NGPM_gp_hash_random_int_subscript_timing_test_insert">
-<div id="NGPM_assoc">
-<div id="NGPM_Native_and_probing_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPM" id="NGPM"><img src="gp_hash_random_int_subscript_timing_test_insert_msvc.png" alt="no image" /></a></h6>NGPM: Native and probing hash random int insert timing test using <tt><b>operator</b></tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_map_ncah-
-<tt>stdext::hash_map</tt></li>
-<li>
-gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a>
-</li>
-<li>
-gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NGPL_res_div">
-<div id="NGPL_local">
-<div id="NGPL_gp_hash_random_int_subscript_timing_test_insert">
-<div id="NGPL_assoc">
-<div id="NGPL_Native_and_probing_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NGPL" id= "NGPL"><img src="gp_hash_random_int_subscript_timing_test_insert_local.png" alt="no image" /></a></h6>NGPL: Native and probing hash random int insert timing test using <tt><b>operator</b></tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="CCGPG_res_div">
-<div id="CCGPG_gcc">
-<div id="CCGPG_ccgp_hash_random_int_subscript_timing_test_insert">
-<div id="CCGPG_assoc">
-<div id="CCGPG_Collision-chaining_and_probing_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="CCGPG" id="CCGPG"><img src="ccgp_hash_random_int_subscript_timing_test_insert_gcc.png" alt="no image" /></a></h6>CCGPG: Collision-chaining and probing hash random int insert timing test using <tt><b>operator</b></tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a>
-</li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="CCGPM_res_div">
-<div id="CCGPM_msvc">
-<div id="CCGPM_ccgp_hash_random_int_subscript_timing_test_insert">
-<div id="CCGPM_assoc">
-<div id="CCGPM_Collision-chaining_and_probing_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="CCGPM" id="CCGPM"><img src="ccgp_hash_random_int_subscript_timing_test_insert_msvc.png" alt="no image" /></a></h6>CCGPM: Collision-chaining and probing hash random int insert timing test using <tt><b>operator</b></tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a>
-</li>
-<li>
-gp_hash_mask_linp_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="linear_probe_fn.html"><tt>linear_probe_fn</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="CCGPL_res_div">
-<div id="CCGPL_local">
-<div id="CCGPL_ccgp_hash_random_int_subscript_timing_test_insert">
-<div id="CCGPL_assoc">
-<div id="CCGPL_Collision-chaining_and_probing_hash_random_int_insert_timing_test_using__tt__b_operator_455b__455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="CCGPL" id= "CCGPL"><img src="ccgp_hash_random_int_subscript_timing_test_insert_local.png" alt="no image" /></a></h6>CCGPL: Collision-chaining and probing hash random int insert timing test using <tt><b>operator</b></tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>In this setting, as in <a href="hash_text_find_find_timing_test.html">Hash-Based Text
- <tt>find</tt> Find Timing Test</a> and <a href="hash_random_int_find_find_timing_test.html">Hash-Based
- Random-Integer <tt>find</tt> Find Timing Test</a> , the choice
- of underlying hash-table underlying hash-table (see <a href="hash_based_containers.html">Design::Associative
- Containers::Hash-Based Containers</a> ) affects performance
- most, then the range-hashing scheme (See <a href="hash_based_containers.html#hash_policies">Design::Associative
- Containers::Hash-Based Containers::Hash Policies</a> ), and,
- only finally, other policies.</p>
-<p>There are some differences, however:</p>
-<ol>
-<li>In this setting, probing tables function sometimes more
- efficiently than collision-chaining tables (see Figures
- <a href="#CCGPG">CCGPG</a> and <a href="#CCGPM">CCGPM</a> ).
- This is explained shortly.</li>
-<li>The performance graphs have a "saw-tooth" shape. The
- average insert time rises and falls. As values are inserted
- into the container, the load factor grows larger. Eventually,
- a resize occurs. The reallocations and rehashing are
- relatively expensive. After this, the load factor is smaller
- than before.</li>
-</ol>
-<p>Collision-chaining containers use indirection for greater
- flexibility; probing containers store values contiguously, in
- an array (see Figure <a href="motivation.html#different_underlying_data_structures">Motivation::Different
- underlying data structures</a> A and B, respectively). It
- follows that for simple data types, probing containers access
- their allocator less frequently than collision-chaining
- containers, (although they still have less efficient probing
- sequences). This explains why some probing containers fare
- better than collision-chaining containers in this case.</p>
-<p>Within each type of hash-table, the range-hashing scheme
- affects performance more than other policies. This is similar
- to the situation in <a href="hash_text_find_find_timing_test.html">Hash-Based Text
- <tt>find</tt> Find Timing Test</a> and <a href="hash_random_int_find_find_timing_test.html">Hash-Based
- Random-Integer <tt>find</tt> Find Timing Test</a>.
- Unsurprisingly, however, containers with <u>lower</u>
-<i>alpha<sub>max</sub></i> perform <u>worse</u> in this case,
- since more re-hashes are performed.</p>
-<p><a href="assoc_performance_tests.html#hash_based_types">Observations::Hash-Based
- Container Types</a> summarizes some observations on hash-based
- containers; <a href="assoc_performance_tests.html#hash_based_policies">Observations::Hash-Based
- Containers' Policies</a> summarizes some observations on
- hash-based containers' policies.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram.png
deleted file mode 100644
index 5c37407dd..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram2.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram2.png
deleted file mode 100644
index 87763caac..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_range_hashing_seq_diagram2.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_ranged_hash_range_hashing_fns.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_ranged_hash_range_hashing_fns.png
deleted file mode 100644
index 5e0d7f403..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_ranged_hash_range_hashing_fns.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_standard_resize_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_standard_resize_policy.html
deleted file mode 100644
index 8dbc57ce2..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_standard_resize_policy.html
+++ /dev/null
@@ -1,795 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>hash_standard_resize_policy Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>hash_standard_resize_policy</tt> Interface</h1>
-
- <p>A resize policy which delegates operations to size and
- trigger policies.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Size_Policy1072992366" id=
-"Size_Policy1072992366"><b>class</b> Size_Policy </a>
-</pre>
- </td>
-
- <td>
- <p>Size policy type.</p>
- </td>
-
- <td><a href=
- "hash_exponential_size_policy.html"><span class="c2"><tt>hash_exponential_size_policy</tt></span></a></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Trigger_Policy3611271815" id=
-"Trigger_Policy3611271815"><b>class</b> Trigger_Policy </a>
-</pre>
- </td>
-
- <td>
- <p>Trigger policy type.</p>
- </td>
-
- <td><a href=
- "hash_load_check_resize_trigger.html"><span class=
- "c2"><tt>hash_load_check_resize_trigger</tt></span></a></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="External_Size_Access1380482982" id=
-"External_Size_Access1380482982"><b>bool</b> External_Size_Access </a>
-</pre>
- </td>
-
- <td>
- <p>Indicates whether physical sizes can be accessed
- externally.</p>
- </td>
-
- <td><tt><b>false</b></tt></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Size_Type42920436" id=
-"Size_Type42920436"><b>typename</b> Size_Type </a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
-
- <td>size_t</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#Size_Policy1072992366"><tt>Size_Policy</tt></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Types and
- Constants</a></h2>
-
- <h3><a name="link4" id="link4">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Size_Type42920436"><tt>Size_Type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link5" id="link5">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="trigger_policy4019166151" id=
-"trigger_policy4019166151">trigger_policy</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Trigger policy type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_policy1385592366" id=
-"size_policy1385592366">size_policy</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Size_Policy1072992366"><tt>Size_Policy</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Size policy type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="external_size_access4043083014" id=
-"external_size_access4043083014">external_size_access</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"#External_Size_Access1380482982"><tt>External_Size_Access</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Indicates whether sizes can be accessed
- externally.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link6" id="link6">Public Methods</a></h2>
-
- <h3><a name="link7" id="link7">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- hash_standard_resize_policy
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- hash_standard_resize_policy
- (<b>const</b> <a href=
-"#Size_Policy1072992366"><tt>Size_Policy</tt></a> &amp;r_size_policy)
-</pre>
- </td>
-
- <td>
- <p>constructor taking some policies <span class=
- "c1"><tt>r_size_policy</tt></span> will be copied by the
- <a href="#Size_Policy1072992366"><tt>Size_Policy</tt></a>
- object of this object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- hash_standard_resize_policy
- (<b>const</b> <a href=
-"#Size_Policy1072992366"><tt>Size_Policy</tt></a> &amp;r_size_policy,
- <b>const</b> <a href=
-"#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a> &amp;r_trigger_policy)
-</pre>
- </td>
-
- <td>
- <p>constructor taking some policies. <span class=
- "c1"><tt>r_size_policy</tt></span> will be copied by the
- <a href="#Size_Policy1072992366"><tt>Size_Policy</tt></a>
- object of this object. <span class=
- "c1"><tt>r_trigger_policy</tt></span> will be copied by
- the <a href=
- "#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a>
- object of this object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b>
- ~hash_standard_resize_policy
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- swap
- (<span class=
-"c2"><tt>hash_standard_resize_policy</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link8" id="link8">Policy Access Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#Size_Policy1072992366"><tt>Size_Policy</tt></a> &amp;
- get_size_policy
- ()
-</pre>
- </td>
-
- <td>
- <p>Access to the <a href=
- "#Size_Policy1072992366"><tt>Size_Policy</tt></a> object
- used.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>const</b> <a href=
-"#Size_Policy1072992366"><tt>Size_Policy</tt></a> &amp;
- get_size_policy
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Const access to the <a href=
- "#Size_Policy1072992366"><tt>Size_Policy</tt></a> object
- used.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href=
-"#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a> &amp;
- get_trigger_policy
- ()
-</pre>
- </td>
-
- <td>
- <p>Access to the <a href=
- "#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a>
- object used.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>const</b> <a href=
-"#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a> &amp;
- get_trigger_policy
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Access to the <a href=
- "#Trigger_Policy3611271815"><tt>Trigger_Policy</tt></a>
- object used.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link9" id="link9">Size Access Methods</a></h3>
-
- <p>These methods are available only if the external size
- parameter indicates that external size access is allowed.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- get_actual_size
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the actual size of the container.</p>
-
- <p>This method returns the number of entries (used and
- unused) in the container. It is different from the
- container's size method, which returns the number of used
- entries. Calling this method will not compile when
- <a href=
- "#External_Size_Access1380482982"><tt>External_Size_Access</tt></a>
- == <tt><b>false</b></tt>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- resize
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> suggested_new_size)
-</pre>
- </td>
-
- <td>
- <p>Resizes the container to <span class=
- "c1"><tt>suggested_new_size</tt></span>, a suggested size
- (the actual size will be determined by the <a href=
- "#Size_Policy1072992366"><tt>Size_Policy</tt></a>
- object).</p>
-
- <p>Calling this method will not compile when <a href=
- "#External_Size_Access1380482982"><tt>External_Size_Access</tt></a>
- == <tt><b>false</b></tt>.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link10" id="link10">Protected Methods</a></h2>
-
- <h3><a name="link11" id="link11">Insert Search
- Notifications.</a></h3>
-
- <p>Notifications called during an insert operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link12" id="link12">Find Search
- Notifications.</a></h3>
-
- <p>Notifications called during a find operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link13" id="link13">Erase Search
- Notifications.</a></h3>
-
- <p>Notifications called during an insert operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link14" id="link14">Content Change
- Notifications</a></h3>
-
- <p>Notifications called when the content of the table changes
- in a way that can affect the resize policy.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_inserted
- (<a href="#size_type55424436"><tt>size_type</tt></a> num_e)
-</pre>
- </td>
-
- <td>
- <p>Notifies an element was inserted.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erased
- (<a href="#size_type55424436"><tt>size_type</tt></a> num_e)
-</pre>
- </td>
-
- <td>
- <p>Notifies an element was erased.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_cleared
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was cleared.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link15" id="link15">Size Change
- Notifications</a></h3>
-
- <p>Notifications called when the table changes size.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_resized
- (<a href="#size_type55424436"><tt>size_type</tt></a> new_size)
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was resized to <span class=
- "c1"><tt>new_size</tt></span>.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link16" id="link16">Queries</a></h3>
-
- <p>Called to query whether/how to resize.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- is_resize_needed
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Queries whether a resize is needed.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#size_type55424436"><tt>size_type</tt></a>
- get_new_size
- (<a href="#size_type55424436"><tt>size_type</tt></a> size,
- <a href=
-"#size_type55424436"><tt>size_type</tt></a> num_used_e) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Queries what the new <span class=
- "c1"><tt>size</tt></span> should be, when the container
- is resized naturally. The current size of the container
- is <span class="c1"><tt>size</tt></span>, and the number
- of used entries within the container is <span class=
- "c1"><tt>num_used_e</tt></span>.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link17" id="link17">Private Methods</a></h2>
-
- <h3><a name="link18" id="link18">Overrides</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <b>void</b>
- do_resize
- (<a href="#size_type55424436"><tt>size_type</tt></a> new_size)
-</pre>
- </td>
-
- <td>
- <p>Resizes to <span class=
- "c1"><tt>new_size</tt></span>.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html
deleted file mode 100644
index 60c30fd34..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_text_find_find_timing_test.html
+++ /dev/null
@@ -1,164 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Hash Text Find Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Hash-Based Text <tt>find</tt> Find Timing Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with keys from an
- arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into
- a container, then performs a series of finds using
- <tt>find</tt> . It measures the average time for <tt>find</tt>
- as a function of the number of values inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/text_find_timing.cc"><tt>text_find_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different range-hashing
- functions, trigger policies, and cache-hashing policies (see
- <a href="hash_based_containers.html#hash_policies">Design::Associative
- Containers::Associative Containers::Hash-Based Containers::Hash
- Policies</a> and <a href="hash_based_containers.html#resize_policies">Design::Associative
- Containers::Hash-Based Containers::Resize Policies</a> ).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NCCG">NCCG</a>, <a href="#NCCM">NCCM</a>
- and <a href="#NCCL">NCCL</a> show the results for the native
- and collision-chaining types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respetively.</p>
-<div id="NCCG_res_div">
-<div id="NCCG_gcc">
-<div id="NCCG_text_find_timing_test_hash">
-<div id="NCCG_assoc">
-<div id="NCCG_Native_and_collision-chaining_hash_text_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCG" id="NCCG"><img src="text_find_timing_test_hash_gcc.png" alt="no image" /></a></h6>NCCG: Native and collision-chaining hash text find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_map_ncah-
-<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_sth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NCCM_res_div">
-<div id="NCCM_msvc">
-<div id="NCCM_text_find_timing_test_hash">
-<div id="NCCM_assoc">
-<div id="NCCM_Native_and_collision-chaining_hash_text_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCM" id="NCCM"><img src="text_find_timing_test_hash_msvc.png" alt="no image" /></a></h6>NCCM: Native and collision-chaining hash text find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_map_ncah-
-<tt>stdext::hash_map</tt></li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_sth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NCCL_res_div">
-<div id="NCCL_local">
-<div id="NCCL_text_find_timing_test_hash">
-<div id="NCCL_assoc">
-<div id="NCCL_Native_and_collision-chaining_hash_text_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NCCL" id= "NCCL"><img src="text_find_timing_test_hash_local.png" alt="no image" /></a></h6>NCCL: Native and collision-chaining hash text find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>In this setting, the range-hashing scheme (See <a href="hash_based_containers.html#hash_policies">Design::Associative
- Containers::Hash-Based Containers::Hash Policies</a> ) affects
- performance more than other policies. As Figure <a href="#NCCG">NCCG</a> shows, containers using mod-based
- range-hashing (including the native hash-based container, which
- is currently hard-wired to this scheme) have lower performance
- than those using mask-based range-hashing. A modulo-based
- range-hashing scheme's main benefit is that it takes into
- account all hash-value bits. Standard string hash-functions are
- designed to create hash values that are nearly-uniform as is [
- <a href="references.html#knuth98sorting">knuth98sorting</a>
- ].</p>
-<p>Trigger policies (see <a href="hash_based_containers.html#resize_policies">Design::Associative
- Containers::Hash-Based Containers::Resize Policies</a> ),
- <i>i.e.</i> the load-checks constants, affect performance to a
- lesser extent.</p>
-<p>Perhaps surprisingly, storing the hash value alongside each
- entry affects performance only marginally, at least in
- <tt>pb_ds</tt> 's implementation. (Unfortunately, it was not
- possible to run the tests with <tt>std::tr1::unordered_map</tt>
- 's <tt>cache_hash_code = <b>true</b></tt> , as it appeared to
- malfuntion.)</p>
-<p><a href="assoc_performance_tests.html#hash_based_policies">Observations::Hash-Based
- Containers' Policies</a> summarizes some observations on
- hash-based containers' policies.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html
deleted file mode 100644
index bfbb3b086..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_find_timing_test.html
+++ /dev/null
@@ -1,163 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Hash Skewed Distribution Memory Use Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Hash-Based Skewed-Distribution Random-Integer <tt>find</tt>
- Find Timing Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with a markedly
- non-uniform i.i.d. integer keys into a container, then performs
- a series of finds using <tt>find</tt> . It measures the average
- time for <tt>find</tt> as a function of the number of values in
- the containers. The keys are generated as follows. First, a
- uniform integer is created; it is then shifted left 8 bits.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/hash_zlob_random_int_find_timing.cc"><tt>hash_zlob_random_int_find_timing_test</tt></a>
- 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different range-hashing
- functions and trigger policies (see <a href="hash_based_containers.html#hash_policies">Design::Associative
- Containers::Hash-Based Containers::Hash Policies</a> and
- <a href="hash_based_containers.html#resize_policies">Design::Associative
- Containers::Hash-Based Containers::Resize Policies</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NHG">NHG</a>, <a href="#NHM">NHM</a>, and
- <a href="#NHL">NHL</a> show the results for various hash-based
- associative-containers in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>MSVC++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NHG_res_div">
-<div id="NHG_gcc">
-<div id="NHG_hash_zlob_random_int_find_timing_test">
-<div id="NHG_assoc">
-<div id="NHG_Skewed-distribution_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="hash_zlob_random_int_find_timing_test_gcc.png" alt="no image" /></a></h6>NHG: Skewed-distribution random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a>
-</li>
-<li>
-n_hash_map_ncah-
-<tt>std::tr1::unordered_map</tt> with <tt>cache_hash_code</tt> = <tt><b>false</b></tt></li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHM_res_div">
-<div id="NHM_msvc">
-<div id="NHM_hash_zlob_random_int_find_timing_test">
-<div id="NHM_assoc">
-<div id="NHM_Skewed-distribution_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="hash_zlob_random_int_find_timing_test_msvc.png" alt="no image" /></a></h6>NHM: Skewed-distribution random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_map_ncah-
-<tt>stdext::hash_map</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-<li>
-gp_hash_mod_quadp_prime_nea_lc_1div8_1div2_nsth_map-
-<a href="gp_hash_table.html"><tt>gp_hash_table</tt></a>
- with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, and <tt>Probe_Fn</tt> = <a href="quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a>
-</li>
-<li>
-cc_hash_mod_prime_nea_lc_1div8_1div1_nsth_map-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/1</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHL_res_div">
-<div id="NHL_local">
-<div id="NHL_hash_zlob_random_int_find_timing_test">
-<div id="NHL_assoc">
-<div id="NHL_Skewed-distribution_random_int_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="hash_zlob_random_int_find_timing_test_local.png" alt="no image" /></a></h6>NHL: Skewed-distribution random int find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>In this setting, the keys' distribution is so skewed that
- the unerlying hash-table type affects performance marginally.
- (This is in contrast with <a href="hash_text_find_find_timing_test.html">Hash-Based Text
- <tt>find</tt> Find Timing Test</a> , <a href="hash_random_int_find_find_timing_test.html">Hash-Based
- Random-Integer <tt>find</tt> Find Timing Test</a> , <a href="hash_random_int_subscript_find_timing_test.html">Hash-Based
- Random-Integer Subscript Find Timing Test</a> and <a href="hash_random_int_subscript_insert_timing_test.html">Hash-Based
- Random-Integer Subscript Insert Timing Test</a> .)</p>
-<p>The range-hashing scheme affects performance dramatically. A
- mask-based range-hashing scheme effectively maps all values
- into the same bucket. Access degenerates into a search within
- an unordered linked-list. In Figures <a href="#NHG">NHG</a> and
- <a href="#NHM">NHM</a> , it should be noted that
- <tt>std::tr1::unordered_map</tt> and <tt>stdext::hash_map</tt>
- are hard-wired currently to mod-based and mask-based schemes,
- respectively.</p>
-<p>When observing the settings of this test, it is apparent
- that the keys' distribution is far from natural. One might ask
- if the test is not contrived to show that, in some cases,
- mod-based range hashing does better than mask-based range
- hashing. This is, in fact just the case. We did not encounter a
- more natural case in which mod-based range hashing is better.
- In our opnion, real-life key distributions are handled better
- with an appropriate hash function and a mask-based
- range-hashing function. (<a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/hash_shift_mask.cc"><tt>shift_mask.cc</tt></a>
- shows an example of handling this a-priori known skewed
- distribution with a mask-based range-hashing function). If hash
- performance is bad, a <i>&Chi;<sup>2</sup></i> test can be used
- to check how to transform it into a more uniform
- distribution.</p>
-<p>For this reason, <tt>pb_ds</tt>'s default range-hashing
- function is mask-based.</p>
-<p><a href="assoc_performance_tests.html#hash_based_types">Observations::Hash-Based
- Container Types</a> summarizes some observations on hash-based
- containers; <a href="assoc_performance_tests.html#hash_based_policies">Observations::Hash-Based
- Containers' Policies</a> summarizes some observations on
- hash-based containers' policies.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_gcc.png
deleted file mode 100644
index 8d170db1a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_local.png
deleted file mode 100644
index 0be2f00fa..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_msvc.png
deleted file mode 100644
index 874e7a780..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/hash_zlob_random_int_find_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/index.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/index.html
deleted file mode 100644
index 4c73c2e91..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/index.html
+++ /dev/null
@@ -1,146 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Policy-Based Data Structures</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Policy-Based Data Structures</h1>
-
- <h5>Ami Tavory and Vladimir Dreizin, IBM Haifa Research
- Laboratories, and Benjamin Kosnik, Red Hat</h5>
-
- <h5><a href="mailto:pbassoc@gmail.com">pbassoc@gmail.com</a></h5>
-
- <p>This is a library of policy-based elementary
- data structures: associative containers and priority queues. It
- is designed for high-performance, flexibility, semantic safety,
- and conformance to the corresponding containers in <tt>std</tt>
- and std::tr1 (except for some points where it differs by
- design).</p>
-
- <p>The documentation is organized as follows:</p>
-
- <ol>
- <li>
- <a href="introduction.html">Introductory</a>
-
- <ol>
- <li><a href="introduction.html">Introduction</a></li>
-
- <li><a href="motivation.html">Motivation</a></li>
-
- <li><a href="prerequisites.html">Usage
- Prerequisites</a></li>
- </ol>
- </li>
-
- <li>
- <a href="interface.html">Interface</a>
-
- <ol>
- <li><a href="tutorial.html">Short Tutorial</a></li>
-
- <li><a href="concepts.html">Concepts</a></li>
-
- <li><a href="interface.html">Specifics</a></li>
- </ol>
- </li>
-
- <li>
- <a href="design.html">Design</a>
-
- <ol>
- <li>
- <a href="assoc_design.html">Associative Containers</a>
-
- <ol>
- <li><a href="ds_gen.html">Data-Structure
- Genericity and Interface</a> </li>
-
- <li><a href="tree_based_containers.html">Tree-Based
- Containers</a></li>
-
- <li><a href="trie_based_containers.html">Trie-Based
- Containers</a></li>
-
- <li><a href="hash_based_containers.html">Hash-Based
- Containers</a></li>
-
- <li><a href="lu_based_containers.html">List-Based
- Containers</a> </li>
- </ol>
- </li>
-
- <li><a href="pq_design.html">Priority Queues</a></li>
- </ol>
- </li>
-
- <li>
- <a href="examples.html">Examples</a>
-
- <ol>
- <li><a href="assoc_examples.html">Associative
- Containers</a></li>
-
- <li><a href="pq_examples.html">Priority Queues</a></li>
- </ol>
- </li>
-
- <li>
- <a href="tests.html">Tests</a>
-
- <ol>
- <li>
- <a href="assoc_tests.html">Associative Containers</a>
-
- <ol>
- <li><a href="assoc_regression_tests.html">Regression
- Tests</a></li>
-
- <li><a href=
- "assoc_performance_tests.html">Performance
- Tests</a></li>
- </ol>
- </li>
-
- <li>
- <a href="pq_tests.html">Priority Queues</a>
-
- <ol>
- <li><a href="pq_regression_tests.html">Regression
- Tests</a></li>
-
- <li><a href="pq_performance_tests.html">Performance
- Tests</a></li>
- </ol>
- </li>
- </ol>
- </li>
-
- <li>
- <a href="misc.html">Misc.</a>
-
- <ol>
- <li><a href="acks.html">Acknowledgments</a></li>
-
- <li><a href="contact.html">Contact</a></li>
-
- <li><a href="disclaimer.html">Disclaimer and
- Copyright</a></li>
-
- <li><a href="references.html">References</a></li>
- </ol>
- </li>
- </ol>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_error.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_error.html
deleted file mode 100644
index 37a89aaf9..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_error.html
+++ /dev/null
@@ -1,53 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
-<title>insert_error Interface</title>
-<meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
-</head>
-
-<body>
-<div id="page">
-<h1><tt>insert_error</tt> Interface</h1>
-
-<p>An entry cannot be inserted into a container object for logical
-reasons (not, e.g., if memory is unavailable, in which case the
-allocator's exception will be thrown).</p>
-
- <p>This exception may be thrown, e.g., when a probe sequence in
- a probing hash table does not encounter any free positions,
- even though free positions are available.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/exception.hpp"><tt>exception.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="exceptions.html"><span class=
-"c2"><tt>insert_error</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram1.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram1.png
deleted file mode 100644
index f64764ec9..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram1.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram2.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram2.png
deleted file mode 100644
index e4645973e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram2.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram3.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram3.png
deleted file mode 100644
index 5535c5fe6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/insert_resize_sequence_diagram3.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/interface.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/interface.html
deleted file mode 100644
index a48a8bbad..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/interface.html
+++ /dev/null
@@ -1,446 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
-<title>Interface</title>
-<meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
-</head>
-
-<body>
-<div id="page">
-<h1>Interface Specifics</h1>
-
-<p>Following are the library's interface specifics. <a href=
- "tutorial.html">Short Tutorial</a> is a short tutorial, and
- <a href="concepts.html">Concepts</a> describes some
- concepts.</p>
- <hr />
-
- <h2><a name="namespaces" id="namespaces">Namespace</a></h2>
-
- <p>All code is enclosed in namespace <tt>pb_ds</tt>. Nested within
- this is namespace <tt>detail</tt>, which contains the parts of this
- library that are considered implementation details.</p>
- <hr />
-
- <h2><a name="containers" id="containers">Containers</a></h2>
-
- <h3><a name="containers_assoc" id=
- "containers_assoc">Associative Containers</a></h3>
-
- <ol>
- <li><a href=
- "container_base.html"><tt>container_base</tt></a> -
- abstract base class for associative containers.</li>
-
- <li>Hash-based:
-
- <ol>
- <li><a href=
- "basic_hash_table.html"><tt>basic_hash_table</tt></a>
- - abstract base class for hash-based
- containers</li>
-
- <li><a href=
- "cc_hash_table.html"><tt>cc_hash_table</tt></a>
- - concrete collision-chaining hash-based
- containers</li>
-
- <li><a href=
- "gp_hash_table.html"><tt>gp_hash_table</tt></a>
- - concrete (general) probing hash-based
- containers</li>
- </ol>
- </li>
-
- <li>Tree-based:
-
- <ol>
- <li><a href=
- "basic_tree.html"><tt>basic_tree</tt></a>
- - abstract base class for tree and trie based
- containers</li>
-
- <li><a href=
- "tree.html"><tt>tree</tt></a>
- - concrete base class for tree-based
- containers</li>
-
- <li><a href=
- "trie.html"><tt>trie</tt></a>
- - concrete base class for trie-based
- containers</li>
- </ol>
- </li>
-
- <li>List-based:
-
- <ol>
- <li><a href=
- "list_update.html"><tt>list_update</tt></a> -
- singly-linked list with update-policy container</li>
- </ol>
- </li>
- </ol>
-
- <h3><a name="containers_pq" id="containers_pq">Priority
- Queues</a></h3>
-
- <ol>
- <li><a href="priority_queue.html"><tt>priority_queue</tt></a>
- - priority queue</li>
- </ol>
- <hr />
-
- <h2><a name="tag" id="tag">Container Tags and
- Traits</a></h2>
-
- <h3><a name="ds_ts" id="ds_ts">Container Tags</a></h3>
-
- <h4><a name="ds_ts_common" id="ds_ts_common">Common</a></h4>
-
- <ol>
- <li><a href="container_tag.html"><tt>container_tag</tt></a> -
- base class for data structure tags</li>
- </ol>
-
- <h4><a name="ds_ts_assoc" id=
- "ds_ts_assoc">Associative-Containers</a></h4>
-
- <ol>
- <li><a href=
- "associative_container_tag.html"><tt>associative_container_tag</tt></a> -
- base class for associative-container data structure tags</li>
-
- <li><a href=
- "basic_hash_tag.html"><tt>basic_hash_tag</tt></a> -
- base class for hash-based structure tags</li>
-
- <li><a href="cc_hash_tag.html"><tt>cc_hash_tag</tt></a>
- - collision-chaining hash structure tag</li>
-
- <li><a href="gp_hash_tag.html"><tt>gp_hash_tag</tt></a>
- - (general) probing hash structure tag</li>
-
- <li><a href=
- "basic_tree_tag.html"><tt>basic_tree_tag</tt></a>
- - base class for tree-like structure tags</li>
-
- <li><a href=
- "tree_tag.html"><tt>tree_tag</tt></a> -
- base class for tree structure tags</li>
-
- <li><a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
- - red-black tree structure tag/li&gt;</li>
-
- <li><a href=
- "splay_tree_tag.html"><tt>splay_tree_tag</tt></a> -
- splay tree structure tag</li>
-
- <li><a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>
- - ordered-vector tree structure tag</li>
-
- <li><a href=
- "trie_tag.html"><tt>trie_tag</tt></a> -
- trie structure tag</li>
-
- <li><a href=
- "pat_trie_tag.html"><tt>pat_trie_tag</tt></a> -
- PATRICIA trie structure tag</li>
-
- <li><a href="list_update_tag.html"><tt>list_update_tag</tt></a> - list
- (with updates) structure tag</li>
- </ol>
-
- <h4><a name="ds_ts_pq" id="ds_ts_pq">Priority-Queues</a></h4>
-
- <ol>
- <li><a href=
- "priority_queue_tag.html"><tt>priority_queue_tag</tt></a> - base
- class for priority-queue data structure tags</li>
-
- <li><a href=
- "pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a> -
- pairing-heap structure tag.</li>
-
- <li><a href=
- "binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
- - binomial-heap structure tag</li>
-
- <li><a href=
- "rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
- - redundant-counter binomial-heap (<i>i.e.</i>, a heap where
- binomial trees form a sequence that is similar to a
- de-amortized bit-addition algorithm) structure tag</li>
-
- <li><a href=
- "binary_heap_tag.html"><tt>binary_heap_tag</tt></a> -
- binary heap (based on an array or an array of nodes)
- structure tag</li>
-
- <li><a href=
- "thin_heap_tag.html"><tt>thin_heap_tag</tt></a> - thin
- heap (an alternative [<a href=
- "references.html#kt99fat_heaps">kt99fat_heaps</a>] to
- Fibonacci heap) data structure tag.</li>
- </ol>
-
- <h3><a name="ds_inv_tag" id="ds_inv_tag">Invalidation-Guarantee
- Tags</a></h3>
-
- <ol>
- <li><a href=
- "basic_invalidation_guarantee.html"><tt>basic_invalidation_guarantee</tt></a>
- - weakest invalidation guarantee</li>
-
- <li><a href=
- "point_invalidation_guarantee.html"><tt>point_invalidation_guarantee</tt></a>
- - stronger invalidation guarantee</li>
-
- <li><a href=
- "range_invalidation_guarantee.html"><tt>range_invalidation_guarantee</tt></a>
- - strongest invalidation guarantee</li>
- </ol>
-
- <h3><a name="container_traits" id="container_traits">Container
- Traits</a></h3>
-
- <ol>
- <li><a href="pq_container_traits.html"><tt>container_traits</tt></a> -
- traits for determining underlying data structure
- properties</li>
- </ol>
- <hr />
-
- <h2><a name="ds_policy_classes" id=
- "ds_policy_classes">Container Policy Classes</a></h2>
-
- <h3><a name="hash_related_policies" id=
- "hash_related_policies">Hash Policies</a></h3>
-
- <h4>Hash and Probe Policies</h4>
-
- <ol>
- <li>Hash Functions:
-
- <ol>
- <li><a href="null_hash_fn.html"><tt>null_hash_fn</tt></a>
- - type indicating one-step range-hashing</li>
- </ol>
- </li>
-
- <li>Range-Hashing Functions:
-
- <ol>
- <li><a href="sample_range_hashing.html">Sample
- range-hashing function</a> - interface required of a
- range-hashing functor</li>
-
- <li><a href=
- "direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
- - (bit) mask-based range hashing functor</li>
-
- <li><a href=
- "direct_mod_range_hashing.html"><tt>direct_mod_range_hashing</tt></a>
- - modulo-based range hashing functor</li>
- </ol>
- </li>
-
- <li>Probe Functions:
-
- <ol>
- <li><a href="sample_probe_fn.html">Sample probe
- function</a> - interface required of a probe functor</li>
-
- <li><a href=
- "null_probe_fn.html"><tt>null_probe_fn</tt></a> - type
- indicating one-step ranged-probe</li>
-
- <li><a href=
- "linear_probe_fn.html"><tt>linear_probe_fn</tt></a> -
- linear-probe functor</li>
-
- <li><a href=
- "quadratic_probe_fn.html"><tt>quadratic_probe_fn</tt></a>-
- quadratic-probe functor</li>
- </ol>
- </li>
-
- <li>Ranged-Hash Functions:
-
- <ol>
- <li><a href="sample_ranged_hash_fn.html">Sample
- ranged-hash function</a> - interface required of a
- ranged-hash functor</li>
- </ol>
- </li>
-
- <li>Ranged-Probe Functions:
-
- <ol>
- <li><a href="sample_ranged_probe_fn.html">Sample
- ranged-probe function</a> - interface required of a
- ranged-probe functor</li>
- </ol>
- </li>
- </ol>
-
- <h4>Resize Policies</h4>
- <ol>
- <li>Resize Policies:
-
- <ol>
- <li><a href="sample_resize_policy.html">Sample resize
- policy</a> - interface required of a resize policy</li>
-
- <li><a href=
- "hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- - standard resize policy</li>
- </ol>
- </li>
-
- <li>Size Policies:
-
- <ol>
- <li><a href="sample_size_policy.html">Sample size
- policy</a> - interface required of a size policy</li>
-
- <li><a href=
- "hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
- - exponential size policy (typically used with (bit) mask
- range-hashing)</li>
-
- <li><a href=
- "hash_prime_size_policy.html"><tt>hash_prime_size_policy</tt></a>
- - prime size policy (typically used with modulo
- range-hashing)</li>
- </ol>
- </li>
-
- <li>Trigger Policies:
-
- <ol>
- <li><a href="sample_resize_trigger.html">Sample trigger
- policy</a> - interface required of a trigger policy</li>
-
- <li><a href=
- "hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- - trigger policy based on load checks</li>
-
- <li><a href=
- "cc_hash_max_collision_check_resize_trigger.html"><tt>cc_hash_max_collision_check_resize_trigger</tt></a>
- - trigger policy based on collision checks</li>
- </ol>
- </li>
- </ol>
-
- <h3><a name="tree_related_policies" id=
- "tree_related_policies">Tree Policies</a></h3>
-
- <h4>Tree Node-Update Policies</h4>
-
-
-<ol>
-<li><a href="sample_tree_node_update.html">Sample node
-updater policy</a> - interface required of a tree
-node-updating functor</li>
-
-<li><a href=
- "null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-- null policy indicating no updates are required</li>
-
-<li><a href=
- "tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a>
-- updater enabling order statistics queries</li>
-</ol>
-
-<h3><a name="trie_related_policies" id=
- "trie_related_policies">Trie Policies</a></h3>
-
-
-<h4>Trie Element-Access Traits</h4>
-
- <ol>
- <li><a href="sample_trie_e_access_traits.html">Sample
- element-access traits</a> - interface required of
- element-access traits</li>
-
- <li><a href=
- "string_trie_e_access_traits.html"><tt>string_trie_e_access_traits</tt></a>
- - String element-access traits</li>
- </ol>
-
- <h4>Trie Node-Update Policies</h4>
-
-
-<ol>
-<li><a href="sample_trie_node_update.html">Sample node
-updater policy</a> - interface required of a trie node
-updater</li>
-
-<li><a href=
- "null_trie_node_update.html"><tt>null_trie_node_update</tt></a>
-- null policy indicating no updates are required</li>
-
-<li><a href=
- "trie_prefix_search_node_update.html"><tt>trie_prefix_search_node_update</tt></a>
-- updater enabling prefix searches</li>
-
-<li><a href=
- "trie_order_statistics_node_update.html"><tt>trie_order_statistics_node_update</tt></a>
-- updater enabling order statistics queries</li>
-</ol>
-
-<h3><a name="list_related_policies" id=
- "list_related_policies">List Policies</a></h3>
-
-<h4>List Update Policies</h4>
-
-
- <ol>
- <li><a href="sample_update_policy.html">Sample list update
- policy</a> - interface required of a list update policy</li>
-
- <li><a href=
- "move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
- - move-to-front update algorithm</li>
-
- <li><a href=
- "counter_lu_policy.html"><tt>counter_lu_policy</tt></a> -
- counter update algorithm</li>
- </ol>
-
- <h3><a name="ds_pol" id="ds_pol">Mapped-Type Policies</a></h3>
-
-
- <ol>
- <li><a href=
- "null_mapped_type.html"><tt>null_mapped_type</tt></a> - data
- policy indicating that a container is a "set"</li>
- </ol>
- <hr />
-
- <h2><a name="exceptions" id="exceptions">Exceptions</a></h2>
-
-
- <ol>
- <li><a href="exceptions.html"><tt>container_error</tt></a>
- - base class for all policy-based data structure errors</li>
-
- <li><a href=
- "insert_error.html"><tt>insert_error</tt></a></li>
-
- <li><a href="join_error.html"><tt>join_error</tt></a></li>
-
- <li><a href=
- "resize_error.html"><tt>resize_error</tt></a></li>
- </ol>
-
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/introduction.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/introduction.html
deleted file mode 100644
index b3ccbd76a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/introduction.html
+++ /dev/null
@@ -1,120 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Introduction</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Introduction</h1>
-
- <p>This section describes what problems the library attempts to
- solve. <a href="motivation.html">Motivation</a> describes the
- reasons we think it solves these problems better than similar
- libraries.</p>
-
- <h2><a name="assoc" id="assoc">Associative Containers</a></h2>
-
- <ol>
- <li>Associative containers depend on their policies to a very
- large extent. Implicitly hard-wiring policies can hamper their
- performance and limit their functionality. An efficient
- hash-based container, for example, requires policies for
- testing key equivalence, hashing keys, translating hash
- values into positions within the hash table, and determining
- when and how to resize the table internally. A tree-based
- container can efficiently support order statistics,
- <i>i.e.</i>, the ability to query what is the order of each
- key within the sequence of keys in the container, but only if
- the container is supplied with a policy to internally update
- meta-data. There are many other such examples.<p></p></li>
-
- <li>Ideally, all associative containers would share the same
- interface. Unfortunately, underlying data structures and
- mapping semantics differentiate between different containers.
- For example, suppose one writes a generic function
- manipulating an associative container <tt>Cntnr</tt>:
- <pre>
-template&lt;typename Cntnr&gt;
- void
- some_op_sequence(Cntnr&amp; r_cnt)
- {
- ...
- }
-</pre>
-
-then what can one assume about <tt>Cntnr</tt>? The answer
-varies according to its underlying data structure. If the
-underlying data structure of <tt>Cntnr</tt> is based on a tree or
-trie, then the order of elements is well defined; otherwise, it is
-not, in general. If the underlying data structure of <tt>Cntnr</tt>
-is based on a collision-chaining hash table, then modifying
-r_<tt>Cntnr</tt> will not invalidate its iterators' order; if the
-underlying data structure is a probing hash table, then this is not
-the case. If the underlying data structure is based on a tree or
-trie, then <tt>r_cnt</tt> can efficiently be split; otherwise, it
-cannot, in general. If the underlying data structure is a red-black
-tree, then splitting <tt>r_cnt</tt> is exception-free; if it is an
-ordered-vector tree, exceptions can be thrown.
- <p></p></li>
- </ol>
-
- <h2><a name="pq" id="pq">Priority Queues</a></h2>
-
- <p>Priority queues are useful when one needs to efficiently
- access a minimum (or maximum) value as the set of values
- changes.</p>
-
- <ol>
- <li>Most useful data structures for priority queues have a
- relatively simple structure, as they are geared toward
- relatively simple requirements. Unfortunately, these structures
- do not support access to an arbitrary value, which turns out to
- be necessary in many algorithms. Say, decreasing an arbitrary
- value in a graph algorithm. Therefore, some extra mechanism is
- necessary and must be invented for accessing arbitrary
- values. There are at least two alternatives: embedding an
- associative container in a priority queue, or allowing
- cross-referencing through iterators. The first solution adds
- significant overhead; the second solution requires a precise
- definition of iterator invalidation. Which is the next
- point...<p></p></li>
-
- <li>Priority queues, like hash-based containers, store values in
- an order that is meaningless and undefined externally. For
- example, a <tt>push</tt> operation can internally reorganize the
- values. Because of this characteristic, describing a priority
- queues' iterator is difficult: on one hand, the values to which
- iterators point can remain valid, but on the other, the logical
- order of iterators can change unpredictably.<p></p></li>
-
- <li>Roughly speaking, any element that is both inserted to a
- priority queue (<i>e.g.</i>, through <tt>push</tt>) and removed
- from it (<i>e.g.</i>, through <tt>pop</tt>), incurs a
- logarithmic overhead (in the amortized sense). Different
- underlying data structures place the actual cost differently:
- some are optimized for amortized complexity, whereas others
- guarantee that specific operations only have a constant
- cost. One underlying data structure might be chosen if modifying
- a value is frequent (Dijkstra's shortest-path algorithm),
- whereas a different one might be chosen
- otherwise. Unfortunately, an array-based binary heap - an
- underlying data structure that optimizes (in the amortized
- sense) <tt>push</tt> and <tt>pop</tt> operations, differs from
- the others in terms of its invalidation guarantees. Other design
- decisions also impact the cost and placement of the overhead, at
- the expense of more difference in the the kinds of operations
- that the underlying data structure can support. These
- differences pose a challenge when creating a uniform interface
- for priority queues.<p></p></li>
- </ol>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_cd.png
deleted file mode 100644
index 1f9d1243c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_cd.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_erase.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_erase.png
deleted file mode 100644
index 940a27f71..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/invalidation_guarantee_erase.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/join_error.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/join_error.html
deleted file mode 100644
index f3e3eaf97..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/join_error.html
+++ /dev/null
@@ -1,48 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
-<title>join_error Interface</title>
-<meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
-</head>
-
-<body>
-<div id="page">
-<h1><tt>join_error</tt> Interface</h1>
-
-<p>A join cannot be performed logical reasons (i.e., the ranges of the
- two container objects
- being joined
- overlaps.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/exception.hpp"><tt>exception.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
-<pre><a href="exceptions.html"><span class="c2"><tt>join_error</tt></span></a>
-</pre>
- </td>
-
-<td>
-<p>public</p>
-</td>
-</tr>
- </table>
- </div>
- </body>
- </html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/linear_probe_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/linear_probe_fn.html
deleted file mode 100644
index 6387d3a33..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/linear_probe_fn.html
+++ /dev/null
@@ -1,140 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>linear_probe_fn Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>linear_probe_fn</tt> Interface</h1>
-
- <p>A probe sequence policy using fixed increments.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Size_Type42920436" id=
-"Size_Type42920436"><b>typename</b> Size_Type </a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
-
- <td>size_t</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Size_Type42920436"><tt>Size_Type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link4" id="link4">Public Methods</a></h2>
-
- <h3><a name="link5" id="link5">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class="c2"><tt>linear_probe_fn</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link6" id="link6">Protected Methods</a></h2>
-
- <h3><a name="link7" id="link7">Offset Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- <b>operator</b>()
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> i) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the <span class="c1"><tt>i</tt></span>-th
- offset from the hash value.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update.html
deleted file mode 100644
index 434e82f42..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update.html
+++ /dev/null
@@ -1,316 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>list_update Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>list_update</tt> Interface</h1>
-
- <p>A list-update based associative container.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Key2501" id="Key2501"><b>typename</b> Key</a>
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a>
-</pre>
- </td>
-
- <td>
- <p>Mapped type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Eq_Fn60085" id="Eq_Fn60085"><b>class</b> Eq_Fn </a>
-</pre>
- </td>
-
- <td>
- <p>Equivalence functor.</p>
- </td>
-
- <td>
- <pre>
-std::equal_to&lt;<a href="#Key2501"><tt>Key</tt></a>&gt;
-</pre>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Update_Policy1671938590" id=
-"Update_Policy1671938590"><b>class</b> Update_Policy </a>
-</pre>
- </td>
-
- <td>
- <p>Update policy (determines when an element will be
- moved to the front of the list.</p>
- </td>
-
- <td><a href="move_to_front_lu_policy.html"><span class=
- "c2"><tt>move_to_front_lu_policy</tt></span></a></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator </a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>
- <pre>
-std::allocator&lt;<b>char</b>&gt;
-</pre>
- </td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="container_base.html"><span class=
-"c2"><tt>container_base</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Types and
- Constants</a></h2>
-
- <h3><a name="link4" id="link4">Policy definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="eq_fn80245" id="eq_fn80245">eq_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Eq_Fn60085"><tt>Eq_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Equivalence functor type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="update_policy894603998" id=
-"update_policy894603998">update_policy</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Update_Policy1671938590"><tt>Update_Policy</tt></a>
-</pre>
- </td>
-
- <td>
- <p>List update policy type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="allocator48440069" id="allocator48440069">allocator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Allocator35940069"><tt>Allocator</tt></a>
-</pre>
- </td>
-
- <td>
- <p><a href="#Allocator35940069"><tt>Allocator</tt></a>
- type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Public Methods</a></h2>
-
- <h3><a name="link6" id="link6">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- list_update
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- list_update
- (It first_it,
- It last_it)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of
- value_types. The value_types between <span class=
- "c1"><tt>first_it</tt></span> and <span class=
- "c1"><tt>last_it</tt></span> will be inserted into the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- list_update
- (<b>const</b> <span class=
-"c2"><tt>list_update</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b>
- ~list_update
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<span class="c2"><tt>list_update</tt></span> &amp;
- <b>operator</b>=
- (<b>const</b> <span class=
-"c2"><tt>list_update</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Assignment operator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class="c2"><tt>list_update</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update_tag.html
deleted file mode 100644
index f04aaeacb..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/list_update_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>list_update_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>list_update_tag</tt> Interface</h1>
-
- <p>List-update data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="associative_container_tag.html"><span class=
-"c2"><tt>associative_container_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu.png
deleted file mode 100644
index 7c96dcaf6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu_based_containers.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu_based_containers.html
deleted file mode 100644
index c8693437d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/lu_based_containers.html
+++ /dev/null
@@ -1,229 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>List-Based Containers</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>List-Update Design</h1>
-
- <h2><a name="overview" id="overview">Overview</a></h2>
-
- <p>The list-based container has the following declaration:</p>
- <pre>
-<b>template</b>&lt;
- <b>typename</b> Key,
- <b>typename</b> Mapped,
- <b>typename</b> Eq_Fn = std::equal_to&lt;Key&gt;,
- <b>typename</b> Update_Policy = <a href=
-"move_to_front_lu_policy.html">move_to_front_lu_policy&lt;&gt;</a>,
- <b>typename</b> Allocator = std::allocator&lt;<b>char</b>&gt; &gt;
-<b>class</b> <a href="list_update.html">list_update</a>;
-</pre>
-
- <p>The parameters have the following meaning:</p>
-
- <ol>
- <li><tt>Key</tt> is the key type.</li>
-
- <li><tt>Mapped</tt> is the mapped-policy, and is explained in
- <a href="tutorial.html#assoc_ms">Tutorial::Associative
- Containers::Associative Containers Others than Maps</a>.</li>
-
- <li><tt>Eq_Fn</tt> is a key equivalence functor.</li>
-
- <li><tt>Update_Policy</tt> is a policy updating positions in
- the list based on access patterns. It is described in the
- following subsection.</li>
-
- <li><tt>Allocator</tt> is an allocator
- type.</li>
- </ol>
-
- <p>A list-based associative container is a container that
- stores elements in a linked-list. It does not order the
- elements by any particular order related to the keys.
- List-based containers are primarily useful for creating
- "multimaps" (see <a href=
- "motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Avoiding Multiple Keys</a> and <a href=
- "tutorial.html#assoc_ms">Tutorial::Associative
- Containers::Associative Containers Others than Maps</a>). In
- fact, list-based containers are designed in <tt>pb_ds</tt>
- expressly for this purpose. This is explained further in
- <a href="#mmaps">Use for "Multimaps"</a>.</p>
-
- <p>List-based containers might also be useful for some rare
- cases, where a key is encapsulated to the extent that only
- key-equivalence can be tested. Hash-based containers need to
- know how to transform a key into a size type, and tree-based
- containers need to know if some key is larger than another.
- List-based associative containers, conversely, only need to
- know if two keys are equivalent.</p>
-
- <p>Since a list-based associative container does not order
- elements by keys, is it possible to order the list in some
- useful manner? Remarkably, many on-line competitive [<a href=
- "references.html#motwani95random">motwani95random</a>]
- algorithms exist for reordering lists to reflect access
- prediction [<a href=
- "references.html#andrew04mtf">andrew04mtf</a>].</p>
-
- <h2><a name="list_updates" id="list_updates">List
- Updates</a></h2>
-
- <h3><a name="general" id="general">General Terms</a></h3>
-
- <p>Figure <a href="#simple_list">A simple list</a> shows a
- simple list of integer keys. If we search for the integer 6, we
- are paying an overhead: the link with key 6 is only the fifth
- link; if it were the first link, it could be accessed
- faster.</p>
-
- <h6 class="c1"><a name="simple_list" id="simple_list"><img src=
- "simple_list.png" alt="no image" /></a></h6>
-
- <h6 class="c1">A simple list.</h6>
-
- <p>List-update algorithms reorder lists as elements are
- accessed. They try to determine, by the access history, which
- keys to move to the front of the list. Some of these algorithms
- require adding some metadata alongside each entry.</p>
-
- <p>For example, Figure <a href="#lu">The counter algorithm</a>
- -A shows the counter algorithm. Each node contains both a key
- and a count metadata (shown in bold). When an element is
- accessed (<i>e.g.</i> 6) its count is incremented, as shown in
- Figure <a href="#lu">The counter algorithm</a> -B. If the count
- reaches some predetermined value, say 10, as shown in Figure
- <a href="#lu">The counter algorithm</a> -C, the count is set to
- 0 and the node is moved to the front of the list, as in Figure
- <a href="#lu">The counter algorithm</a> -D.</p>
-
- <h6 class="c1"><a name="lu" id="lu"><img src="lu.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">The counter algorithm.</h6>
-
- <h3><a name="imp_pb_ds" id="imp_pb_ds">Implementation</a></h3>
-
- <p><tt>pb_ds</tt> allows instantiating lists with policies
- implementing any algorithm moving nodes to the front of the
- list (policies implementing algorithms interchanging nodes are
- unsupported).</p>
-
- <p>Associative containers based on lists are parametrized by a
- <tt>Update_Policy</tt> parameter. This parameter defines the
- type of metadata each node contains, how to create the
- metadata, and how to decide, using this metadata, whether to
- move a node to the front of the list. A list-based associative
- container object derives (publicly) from its update policy.
- Figure <a href="#update_policy_cd">A list and its update
- policy</a> shows the scheme, as well as some predefined
- policies (which are explained below).</p>
-
- <h6 class="c1"><a name="update_policy_cd" id=
- "update_policy_cd"><img src="update_policy_cd.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">A list and its update policy.</h6>
-
- <p>An instantiation of <tt>Update_Policy</tt> must define
- internally <tt>update_metadata</tt> as the metadata it
- requires. Internally, each node of the list contains, besides
- the usual key and data, an instance of <tt><b>typename</b>
- Update_Policy::update_metadata</tt>.</p>
-
- <p>An instantiation of <tt>Update_Policy</tt> must define
- internally two operators:</p>
- <pre>
-update_metadata
-<b>operator</b>()();
-
-<b>bool</b>
-<b>operator</b>()(update_metadata &amp;);
-</pre>
-
- <p>The first is called by the container object, when creating a
- new node, to create the node's metadata. The second is called
- by the container object, when a node is accessed (<i>e.g.</i>,
- when a find operation's key is equivalent to the key of the
- node), to determine whether to move the node to the front of
- the list.</p>
-
- <p>The library contains two predefined implementations of
- list-update policies [<a href=
- "references.html#andrew04mtf">andrew04mtf</a>]. The first is
- <a href=
- "counter_lu_policy.html"><tt>counter_lu_policy</tt></a>, which
- implements the counter algorithm described above. The second is
- <a href=
- "move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>,
- which unconditionally move an accessed element to the front of
- the list. The latter type is very useful in <tt>pb_ds</tt>,
- since there is no need to associate metadata with each element
- (this is explained further in <a href="#mmaps">Use for
- "Multimaps"</a>).</p>
-
- <h2><a name="mmaps" id="mmaps">Use for "Multimaps"</a></h2>
-
- <p>In <tt>pb_ds</tt>, there are no equivalents for the STL's
- multimaps and multisets; instead one uses an associative
- container mapping primary keys to secondary keys (see <a href=
- "motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Alternative to Multiple Equivalent Keys</a> and
- <a href="tutorial.html#assoc_ms">Tutorial::Associative
- Containers::Associative Containers Others than Maps</a>).</p>
-
- <p>List-based containers are especially useful as associative
- containers for secondary keys. In fact, they are implemented
- here expressly for this purpose.</p>
-
- <p>To begin with, these containers use very little per-entry
- structure memory overhead, since they can be implemented as
- singly-linked lists. (Arrays use even lower per-entry memory
- overhead, but they are less flexible in moving around entries,
- and have weaker invalidation guarantees).</p>
-
- <p>More importantly, though, list-based containers use very
- little per-container memory overhead. The memory overhead of an
- empty list-based container is practically that of a pointer.
- This is important for when they are used as secondary
- associative-containers in situations where the average ratio of
- secondary keys to primary keys is low (or even 1).</p>
-
- <p>In order to reduce the per-container memory overhead as much
- as possible, they are implemented as closely as possible to
- singly-linked lists.</p>
-
- <ol>
- <li>List-based containers do not store internally the number
- of values that they hold. This means that their <tt>size</tt>
- method has linear complexity (just like <tt>std::list</tt>).
- Note that finding the number of equivalent-key values in an
- STL multimap also has linear complexity (because it must be
- done, <i>e.g.</i>, via <tt>std::distance</tt> of the
- multimap's <tt>equal_range</tt> method), but usually with
- higher constants.</li>
-
- <li>Most associative-container objects each hold a policy
- object (<i>e.g.</i>, a hash-based container object holds a
- hash functor). List-based containers, conversely, only have
- class-wide policy objects.</li>
- </ol>
-
- <p>See also <a href=
- "assoc_performance_tests.html#msc">Associative-Container
- Performance Tests::Observations::Mapping-Semantics
- Considerations</a>.</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/misc.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/misc.html
deleted file mode 100644
index 01029e134..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/misc.html
+++ /dev/null
@@ -1,26 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Misc.</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Misc.</h1>
-
- <p><a href="acks.html" title="Acknowledgements">Acks</a>
- contains acknowledgments; <a href="contact.html">Contact</a>
- contains contact information;<a href=
- "disclaimer.html">Disclaimer and Copyright</a> is a standard
- disclaimer, and <a href="references.html">References</a>
- contains references.</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/motivation.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/motivation.html
deleted file mode 100644
index 627317217..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/motivation.html
+++ /dev/null
@@ -1,993 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Motivation</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Motivation</h1>
-
- <p>Many fine associative-container libraries were already
- written, most notably, the STL's associative containers. Why
- then write another library? This section shows some possible
- advantages of this library, when considering the challenges in
- <a href="introduction.html">Introduction</a>. Many of these
- points stem from the fact that the STL introduced
- associative-containers in a two-step process (first
- standardizing tree-based containers, only then adding
- hash-based containers, which are fundamentally different), did
- not standardize priority queues as containers, and (in our
- opinion) overloads the iterator concept.</p>
-
- <h2><a name="assoc" id="assoc">Associative Containers</a></h2>
-
- <h3><a name="assoc_policies" id="assoc_policies">More
- Configuration Choices</a></h3>
-
- <p>Associative containers require a relatively large number of
- policies to function efficiently in various settings. In some
- cases this is needed for making their common operations more
- efficient, and in other cases this allows them to support a
- larger set of operations</p>
-
- <ol>
- <li>Hash-based containers, for example, support look-up and
- insertion methods (<i>e.g.</i>, <tt>find</tt> and
- <tt>insert</tt>). In order to locate elements quickly, they
- are supplied a hash functor, which instruct how to transform
- a key object into some size type; <i>e.g.</i>, a hash functor
- might transform <tt>"hello"</tt> into <tt>1123002298</tt>. A
- hash table, though, requires transforming each key object
- into some size-type type in some specific domain;
- <i>e.g.</i>, a hash table with a 128-long table might
- transform <tt>"hello"</tt> into position 63. The policy by
- which the hash value is transformed into a position within
- the table can dramatically affect performance (see <a href=
- "hash_based_containers.html#hash_policies">Design::Associative
- Containers::Hash-Based Containers::Hash Policies</a>).
- Hash-based containers also do not resize naturally (as
- opposed to tree-based containers, for example). The
- appropriate resize policy is unfortunately intertwined with
- the policy that transforms hash value into a position within
- the table (see <a href=
- "hash_based_containers.html#resize_policies">Design::Associative
- Containers::Hash-Based Containers::Resize Policies</a>).
-
- <p><a href=
- "assoc_performance_tests.html#hash_based">Associative-Container
- Performance Tests::Hash-Based Containers</a> quantifies
- some of these points.</p>
- </li>
-
- <li>Tree-based containers, for example, also support look-up
- and insertion methods, and are primarily useful when
- maintaining order between elements is important. In some
- cases, though, one can utilize their balancing algorithms for
- completely different purposes.
-
- <p>Figure <a href="#node_invariants">Metadata for
- order-statistics and interval intersections</a>-A, for
- example, shows a tree whose each node contains two entries:
- a floating-point key, and some size-type <i>metadata</i>
- (in bold beneath it) that is the number of nodes in the
- sub-tree. (<i>E.g.</i>, the root has key 0.99, and has 5
- nodes (including itself) in its sub-tree.) A container based
- on this data structure can obviously answer efficiently
- whether 0.3 is in the container object, but it can also
- answer what is the order of 0.3 among all those in the
- container object [<a href=
- "references.html#clrs2001">clrs2001</a>] (see <a href=
- "assoc_examples.html#tree_like_based">Associative Container
- Examples::Tree-Like-Based Containers (Trees and
- Tries)</a>).</p>
-
- <p>As another example, Figure <a href=
- "#node_invariants">Metadata for order-statistics and
- interval intersections</a>-B shows a tree whose each node
- contains two entries: a half-open geometric line interval,
- and a number <i>metadata</i> (in bold beneath it) that is
- the largest endpoint of all intervals in its sub-tree.
- (<i>E.g.</i>, the root describes the interval <i>[20,
- 36)</i>, and the largest endpoint in its sub-tree is 99.) A
- container based on this data structure can obviously answer
- efficiently whether <i>[3, 41)</i> is in the container
- object, but it can also answer efficiently whether the
- container object has intervals that intersect <i>[3,
- 41)</i> (see <a href=
- "assoc_examples.html#tree_like_based">Associative Container
- Examples::Tree-Like-Based Containers (Trees and
- Tries)</a>). These types of queries are very useful in
- geometric algorithms and lease-management algorithms.</p>
-
- <p>It is important to note, however, that as the trees are
- modified, their internal structure changes. To maintain
- these invariants, one must supply some policy that is aware
- of these changes (see <a href=
- "tree_based_containers.html#invariants">Design::Associative
- Containers::Tree-Based Containers::Node Invariants</a>);
- without this, it would be better to use a linked list (in
- itself very efficient for these purposes).</p>
-
- <p><a href=
- "assoc_performance_tests.html#tree_like_based">Associative-Container
- Performance Tests::Tree-Like-Based Containers</a>
- quantifies some of these points.</p>
- </li>
- </ol>
-
- <h6 class="c1"><a name="node_invariants" id=
- "node_invariants"><img src="node_invariants.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Metadata for order-statistics and interval
- intersections.</h6>
-
- <h3><a name="assoc_ds_genericity" id="assoc_ds_genericity">More
- Data Structures and Traits</a></h3>
-
- <p>The STL contains associative containers based on red-black
- trees and collision-chaining hash tables. These are obviously
- very useful, but they are not ideal for all types of
- settings.</p>
-
- <p>Figure <a href=
- "#different_underlying_data_structures">Different underlying
- data structures</a> shows different underlying data structures
- (the ones currently supported in <tt>pb_ds</tt>). A shows a
- collision-chaining hash-table, B shows a probing hash-table, C
- shows a red-black tree, D shows a splay tree, E shows a tree
- based on an ordered vector(implicit in the order of the
- elements), F shows a PATRICIA trie, and G shows a list-based
- container with update policies.</p>
-
- <p>Each of these data structures has some performance benefits,
- in terms of speed, size or both (see <a href=
- "assoc_performance_tests.html">Associative-Container
- Performance Tests</a> and <a href=
- "assoc_performance_tests.html#dss_family_choice">Associative-Container
- Performance Tests::Observations::Underlying Data-Structure
- Families</a>). For now, though, note that <i>e.g.</i>,
- vector-based trees and probing hash tables manipulate memory
- more efficiently than red-black trees and collision-chaining
- hash tables, and that list-based associative containers are
- very useful for constructing "multimaps" (see <a href=
- "#assoc_mapping_semantics">Alternative to Multiple Equivalent
- Keys</a>, <a href=
- "assoc_performance_tests.html#multimaps">Associative Container
- Performance Tests::Multimaps</a>, and <a href=
- "assoc_performance_tests.html#msc">Associative Container
- Performance Tests::Observations::Mapping-Semantics
- Considerations</a>).</p>
-
- <h6 class="c1"><a name="different_underlying_data_structures"
- id="different_underlying_data_structures"><img src=
- "different_underlying_dss.png" alt="no image" /></a></h6>
-
- <h6 class="c1">Different underlying data structures.</h6>
-
- <p>Now consider a function manipulating a generic associative
- container, <i>e.g.</i>,</p>
- <pre>
-<b>template</b>&lt;
- <b>class</b> Cntnr&gt;
-<b>int</b>
- some_op_sequence
- (Cntnr &amp;r_cnt)
-{
- ...
-}
-</pre>
-
- <p>Ideally, the underlying data structure of <tt>Cntnr</tt>
- would not affect what can be done with <tt>r_cnt</tt>.
- Unfortunately, this is not the case.</p>
-
- <p>For example, if <tt>Cntnr</tt> is <tt>std::map</tt>, then
- the function can use <tt>std::for_each(r_cnt.find(foo),
- r_cnt.find(bar), foobar)</tt> in order to apply <tt>foobar</tt>
- to all elements between <tt>foo</tt> and <tt>bar</tt>. If
- <tt>Cntnr</tt> is a hash-based container, then this call's
- results are undefined.</p>
-
- <p>Also, if <tt>Cntnr</tt> is tree-based, the type and object
- of the comparison functor can be accessed. If <tt>Cntnr</tt> is
- hash based, these queries are nonsensical.</p>
-
- <p>There are various other differences based on the container's
- underlying data structure. For one, they can be constructed by,
- and queried for, different policies. Furthermore:</p>
-
- <ol>
- <li>Containers based on C, D, E and F store elements in a
- meaningful order; the others store elements in a meaningless
- (and probably time-varying) order. By implication, only
- containers based on C, D, E and F can support erase
- operations taking an iterator and returning an iterator to
- the following element without performance loss (see <a href=
- "#assoc_ers_methods">Slightly Different Methods::Methods
- Related to Erase</a>).</li>
-
- <li>Containers based on C, D, E, and F can be split and
- joined efficiently, while the others cannot. Containers based
- on C and D, furthermore, can guarantee that this is
- exception-free; containers based on E cannot guarantee
- this.</li>
-
- <li>Containers based on all but E can guarantee that erasing
- an element is exception free; containers based on E cannot
- guarantee this. Containers based on all but B and E can
- guarantee that modifying an object of their type does not
- invalidate iterators or references to their elements, while
- containers based on B and E cannot. Containers based on C, D,
- and E can furthermore make a stronger guarantee, namely that
- modifying an object of their type does not affect the order
- of iterators.</li>
- </ol>
-
- <p>A unified tag and traits system (as used for the STL's
- iterators, for example) can ease generic manipulation of
- associative containers based on different underlying
- data structures (see <a href=
- "tutorial.html#assoc_ds_gen">Tutorial::Associative
- Containers::Determining Containers' Attributes</a> and <a href=
- "ds_gen.html#container_traits">Design::Associative
- Containers::Data-Structure Genericity::Data-Structure Tags and
- Traits</a>).</p>
-
- <h3><a name="assoc_diff_it" id="assoc_diff_it">Differentiating
- between Iterator Types</a></h3>
-
- <p>Iterators are centric to the STL's design, because of the
- container/algorithm/iterator decomposition that allows an
- algorithm to operate on a range through iterators of some
- sequence (<i>e.g.</i>, one originating from a container).
- Iterators, then, are useful because they allow going over a
- <u>sequence</u>. The STL also uses iterators for accessing a
- <u>specific</u> element - <i>e.g.</i>, when an associative
- container returns one through <tt>find</tt>. The STL, however,
- consistently uses the same types of iterators for both
- purposes: going over a range, and accessing a specific found
- element. Before the introduction of hash-based containers to
- the STL, this made sense (with the exception of priority
- queues, which are discussed in <a href="#pq">Priority
- Queues</a>).</p>
-
- <p>Using the STL's associative containers together with
- non-order-preserving associative containers (and also because
- of priority-queues container), there is a possible need for
- different types of iterators for self-organizing containers -
- the iterator concept seems overloaded to mean two different
- things (in some cases). The following subsections explain this;
- <a href="tutorial.html#assoc_find_range">Tutorial::Associative
- Containers::Point-Type and Range-Type Methods</a> explains an
- alternative design which does not complicate the use of
- order-preserving containers, but is better for unordered
- containers; <a href=
- "ds_gen.html#find_range">Design::Associative
- Containers::Data-Structure Genericity::Point-Type and
- Range-Type Methods</a> explains the design further.</p>
-
- <h4><a name="assoc_find_it_range_it" id=
- "assoc_find_it_range_it">Using Point-Type Iterators for
- Range-Type Operations</a></h4>
-
- <p>Suppose <tt>cntnr</tt> is some associative container, and
- say <tt>c</tt> is an object of type <tt>cntnr</tt>. Then what
- will be the outcome of</p>
- <pre>
-std::for_each(c.find(1), c.find(5), foo);
-</pre>
-
- <p>If <tt>cntnr</tt> is a tree-based container object, then an
- in-order walk will apply <tt>foo</tt> to the relevant elements,
- <i>e.g.</i>, as in Figure <a href="#range_it_in_hts">Range
- iteration in different data structures</a> -A. If <tt>c</tt> is
- a hash-based container, then the order of elements between any
- two elements is undefined (and probably time-varying); there is
- no guarantee that the elements traversed will coincide with the
- <i>logical</i> elements between 1 and 5, <i>e.g.</i>, as in
- Figure <a href="#range_it_in_hts">Range iteration in different
- data structures</a>-B.</p>
-
- <h6 class="c1"><a name="range_it_in_hts" id=
- "range_it_in_hts"><img src="point_iterators_range_ops_1.png"
- alt="no image" /></a></h6>
-
- <h6 class="c1">Range iteration in different
- data structures.</h6>
-
- <p>In our opinion, this problem is not caused just because
- red-black trees are order preserving while collision-chaining
- hash tables are (generally) not - it is more fundamental. Most
- of the STL's containers order sequences in a well-defined
- manner that is determined by their <u>interface</u>: calling
- <tt>insert</tt> on a tree-based container modifies its sequence
- in a predictable way, as does calling <tt>push_back</tt> on a
- list or a vector. Conversely, collision-chaining hash tables,
- probing hash tables, priority queues, and list-based containers
- (which are very useful for "multimaps") are self-organizing
- data structures; the effect of each operation modifies their
- sequences in a manner that is (practically) determined by their
- <u>implementation</u>.</p>
-
- <p>Consequently, applying an algorithm to a sequence obtained
- from most containers <u>may or may not</u> make sense, but
- applying it to a sub-sequence of a self-organizing container
- <u>does not</u>.</p>
-
- <h4><a name="assoc_range_it_for_find_it" id=
- "assoc_range_it_for_find_it">The Cost of Enabling Range
- Capabilities to Point-Type Iterators</a></h4>
-
- <p>Suppose <tt>c</tt> is some collision-chaining hash-based
- container object, and one calls <tt>c.find(3)</tt>. Then what
- composes the returned iterator?</p>
-
- <p>Figure <a href="#find_its_in_hash_tables">Point-type
- iterators in hash tables</a>-A shows the simplest (and most
- efficient) implementation of a collision-chaining hash table.
- The little box marked <tt>point_iterator</tt> shows an object
- that contains a pointer to the element's node. Note that this
- "iterator" has no way to move to the next element (<i>i.e.</i>,
- it cannot support <tt><b>operator</b>++</tt>). Conversely, the
- little box marked <tt>iterator</tt> stores both a pointer to
- the element, as well as some other information (<i>e.g.</i>,
- the bucket number of the element). the second iterator, then,
- is "heavier" than the first one- it requires more time and
- space. If we were to use a different container to
- cross-reference into this hash-table using these iterators - it
- would take much more space. As noted in <a href=
- "#assoc_find_it_range_it">Using Point-Type Iterators for
- Range-Type Operations</a>, nothing much can be done by
- incrementing these iterators, so why is this extra information
- needed?</p>
-
- <p>Alternatively, one might create a collision-chaining
- hash-table where the lists might be linked, forming a
- monolithic total-element list, as in Figure <a href=
- "#find_its_in_hash_tables">Point-type iterators in hash
- tables</a>-B (this seems similar to the Dinkumware design
- [<a href="references.html#dinkumware_stl">dinkumware_stl</a>]).
- Here the iterators are as light as can be, but the hash-table's
- operations are more complicated.</p>
-
- <h6 class="c1"><a name="find_its_in_hash_tables" id=
- "find_its_in_hash_tables"><img src=
- "point_iterators_range_ops_2.png" alt="no image" /></a></h6>
-
- <h6 class="c1">Point-type iterators in hash tables.</h6>
-
- <p>It should be noted that containers based on
- collision-chaining hash-tables are not the only ones with this
- type of behavior; many other self-organizing data structures
- display it as well.</p>
-
- <h4><a name="assoc_inv_guar" id="assoc_inv_guar">Invalidation
- Guarantees</a></h4>
-
- <p>Consider the following snippet:</p>
- <pre>
-it = c.find(3);
-
-c.erase(5);
-</pre>
-
- <p>Following the call to <tt>erase</tt>, what is the validity
- of <tt>it</tt>: can it be de-referenced? can it be
- incremented?</p>
-
- <p>The answer depends on the underlying data structure of the
- container. Figure <a href=
- "#invalidation_guarantee_erase">Effect of erase in different
- underlying data structures</a> shows three cases: A1 and A2
- show a red-black tree; B1 and B2 show a probing hash-table; C1
- and C2 show a collision-chaining hash table.</p>
-
- <h6 class="c1"><a name="invalidation_guarantee_erase" id=
- "invalidation_guarantee_erase"><img src=
- "invalidation_guarantee_erase.png" alt="no image" /></a></h6>
-
- <h6 class="c1">Effect of erase in different underlying
- data structures.</h6>
-
- <ol>
- <li>Erasing 5 from A1 yields A2. Clearly, an iterator to 3
- can be de-referenced and incremented. The sequence of
- iterators changed, but in a way that is well-defined by the
- <u>interface</u>.</li>
-
- <li>Erasing 5 from B1 yields B2. Clearly, an iterator to 3 is
- not valid at all - it cannot be de-referenced or incremented;
- the order of iterators changed in a way that is (practically)
- determined by the <u>implementation</u> and not by the
- <u>interface</u>.</li>
-
- <li>Erasing 5 from C1 yields C2. Here the situation is more
- complicated. On the one hand, there is no problem in
- de-referencing <tt>it</tt>. On the other hand, the order of
- iterators changed in a way that is (practically) determined
- by the <u>implementation</u> and not by the
- <u>interface</u>.</li>
- </ol>
-
- <p>So in classic STL, it is not always possible to express
- whether <tt>it</tt> is valid or not. This is true also for
- <tt>insert</tt>, <i>e.g.</i>. Again, the iterator concept seems
- overloaded.</p>
-
- <h3><a name="assoc_methods" id="assoc_methods">Slightly
- Different Methods</a></h3>
-
- <p>[<a href="references.html#meyers02both">meyers02both</a>]
- points out that a class's methods should comprise only
- operations which depend on the class's internal structure;
- other operations are best designed as external functions.
- Possibly, therefore, the STL's associative containers lack some
- useful methods, and provide some other methods which would be
- better left out (<i>e.g.</i>, [<a href=
- "references.html#sgi_stl">sgi_stl</a>] ).</p>
-
- <h4><a name="assoc_ers_methods" id="assoc_ers_methods">Methods
- Related to Erase</a></h4>
-
- <ol>
- <li>Order-preserving STL associative containers provide the
- method
- <pre>
-iterator
- erase
- (iterator it)
-</pre>which takes an iterator, erases the corresponding element,
-and returns an iterator to the following element. Also hash-based
-STL associative containers provide this method. This <u>seemingly
-increases</u> genericity between associative containers, since, <i>
- e.g.</i>, it is possible to use
- <pre>
-<b>typename</b> C::iterator it = c.begin();
-<b>typename</b> C::iterator e_it = c.end();
-
-<b>while</b>(it != e_it)
- it = pred(*it)? c.erase(it) : ++it;
-</pre>in order to erase from a container object <tt>
- c</tt> all element which match a predicate <tt>pred</tt>.
- However, in a different sense this actually
- <u>decreases</u> genericity: an integral implication of
- this method is that tree-based associative containers'
- memory use is linear in the total number of elements they
- store, while hash-based containers' memory use is unbounded
- in the total number of elements they store. Assume a
- hash-based container is allowed to decrease its size when
- an element is erased. Then the elements might be rehashed,
- which means that there is no "next" element - it is simply
- undefined. Consequently, it is possible to infer from the
- fact that STL hash-based containers provide this method
- that they cannot downsize when elements are erased
- (<a href="assoc_performance_tests.html#hash_based">Performance
- Tests::Hash-Based Container Tests</a> quantifies this.) As
- a consequence, different code is needed to manipulate
- different containers, assuming that memory should be
- conserved. <tt>pb_ds</tt>'s non-order preserving
- associative containers omit this method.
- </li>
-
- <li>All of <tt>pb_ds</tt>'s associative containers include a
- conditional-erase method
- <pre>
-<b>template</b>&lt;
- <b>class</b> Pred&gt;
-size_type
- erase_if
- (Pred pred)
-</pre>which erases all elements matching a predicate. This is
-probably the only way to ensure linear-time multiple-item erase
-which can actually downsize a container.
- </li>
-
- <li>STL associative containers provide methods for
- multiple-item erase of the form
- <pre>
-size_type
- erase
- (It b,
- It e)
-</pre>erasing a range of elements given by a pair of iterators. For
-tree-based or trie-based containers, this can implemented more
-efficiently as a (small) sequence of split and join operations. For
-other, unordered, containers, this method isn't much better than an
-external loop. Moreover, if <tt>c</tt> is a hash-based container,
-then, <i>e.g.</i>, <tt>c.erase(c.find(2), c.find(5))</tt> is almost
-certain to do something different than erasing all elements whose
-keys are between 2 and 5, and is likely to produce other undefined
-behavior.
- </li>
- </ol>
-
- <h4><a name="assoc_split_join_methods" id=
- "assoc_split_join_methods">Methods Related to Split and
- Join</a></h4>
-
- <p>It is well-known that tree-based and trie-based container
- objects can be efficiently split or joined [<a href=
- "references.html#clrs2001">clrs2001</a>]. Externally splitting
- or joining trees is super-linear, and, furthermore, can throw
- exceptions. Split and join methods, consequently, seem good
- choices for tree-based container methods, especially, since as
- noted just before, they are efficient replacements for erasing
- sub-sequences. <a href=
- "assoc_performance_tests.html#tree_like_based">Performance
- Tests::Tree-Like-Based Container Tests</a> quantifies this.</p>
-
- <h4><a name="assoc_insert_methods" id=
- "assoc_insert_methods">Methods Related to Insert</a></h4>
-
- <p>STL associative containers provide methods of the form</p>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
-size_type
- insert
- (It b,
- It e);
-</pre>for inserting a range of elements given by a pair of
-iterators. At best, this can be implemented as an external loop,
-or, even more efficiently, as a join operation (for the case of
-tree-based or trie-based containers). Moreover, these methods seem
-similar to constructors taking a range given by a pair of
-iterators; the constructors, however, are transactional, whereas
-the insert methods are not; this is possibly confusing.
-
- <h4><a name="assoc_equiv_comp_methods" id=
- "assoc_equiv_comp_methods">Functions Related to
- Comparison</a></h4>
-
- <p>Associative containers are parametrized by policies
- allowing to test key equivalence; <i>e.g.</i> a hash-based
- container can do this through its equivalence functor, and a
- tree-based container can do this through its comparison
- functor. In addition, some STL associative containers have
- global function operators, <i>e.g.</i>,
- <tt><b>operator</b>==</tt> and <tt><b>operator</b>&lt;=</tt>,
- that allow comparing entire associative containers.</p>
-
- <p>In our opinion, these functions are better left out. To
- begin with, they do not significantly improve over an external
- loop. More importantly, however, they are possibly misleading -
- <tt><b>operator</b>==</tt>, for example, usually checks for
- equivalence, or interchangeability, but the associative
- container cannot check for values' equivalence, only keys'
- equivalence; also, are two containers considered equivalent if
- they store the same values in different order? this is an
- arbitrary decision.</p>
-
- <h3><a name="assoc_mapping_semantics" id=
- "assoc_mapping_semantics">Alternative to Multiple Equivalent
- Keys</a></h3>
-
- <p>Maps (or sets) allow mapping (or storing) unique-key values.
- The STL, however, also supplies associative containers which
- map (or store) multiple values with equivalent keys:
- <tt>std::multimap</tt>, <tt>std::multiset</tt>,
- <tt>std::tr1::unordered_multimap</tt>, and
- <tt>unordered_multiset</tt>. We first discuss how these might
- be used, then why we think it is best to avoid them.</p>
-
- <p>Suppose one builds a simple bank-account application that
- records for each client (identified by an <tt>std::string</tt>)
- and account-id (marked by an <tt><b>unsigned long</b></tt>) -
- the balance in the account (described by a
- <tt><b>float</b></tt>). Suppose further that ordering this
- information is not useful, so a hash-based container is
- preferable to a tree based container. Then one can use</p>
- <pre>
-std::tr1::unordered_map&lt;std::pair&lt;std::string, <b>unsigned long</b>&gt;, <b>float</b>, ...&gt;
-</pre>which <u>hashes every combination of client and
-account-id</u>. This might work well, except for the fact that it
-is now impossible to efficiently list all of the accounts of a
-specific client (this would practically require iterating over all
-entries). Instead, one can use
- <pre>
-std::tr1::unordered_multimap&lt;std::pair&lt;std::string, <tt><b>unsigned long</b></tt>&gt;, <b>float</b>, ...&gt;
-</pre>which <u>hashes every client</u>, and <u>decides equivalence
-based on client</u> only. This will ensure that all accounts
-belonging to a specific user are stored consecutively.
-
- <p>Also, suppose one wants an integers' priority queue
- (<i>i.e.,</i> a container that supports <tt>push</tt>,
- <tt>pop</tt>, and <tt>top</tt> operations, the last of which
- returns the largest <tt><b>int</b></tt>) that also supports
- operations such as <tt>find</tt> and <tt>lower_bound</tt>. A
- reasonable solution is to build an adapter over
- <tt>std::set&lt;<b>int</b>&gt;</tt>. In this adapter,
- <i>e.g.</i>, <tt>push</tt> will just call the tree-based
- associative container's <tt>insert</tt> method; <tt>pop</tt>
- will call its <tt>end</tt> method, and use it to return the
- preceding element (which must be the largest). Then this might
- work well, except that the container object cannot hold
- multiple instances of the same integer (<tt>push(4)</tt>,
- <i>e.g.</i>, will be a no-op if <tt>4</tt> is already in the
- container object). If multiple keys are necessary, then one
- might build the adapter over an
- <tt>std::multiset&lt;<b>int</b>&gt;</tt>.</p>
-
- <p class="c1">STL non-unique-mapping containers, then, are
- useful when (1) a key can be decomposed in to a primary key and
- a secondary key, (2) a key is needed multiple times, or (3) any
- combination of (1) and (2).</p>
-
- <p>Figure <a href="#embedded_lists_1">Non-unique mapping
- containers in the STL's design</a> shows how the STL's design
- works internally; in this figure nodes shaded equally represent
- equivalent-key values. Equivalent keys are stored consecutively
- using the properties of the underlying data structure: binary
- search trees (Figure <a href="#embedded_lists_1">Non-unique
- mapping containers in the STL's design</a>-A) store
- equivalent-key values consecutively (in the sense of an
- in-order walk) naturally; collision-chaining hash tables
- (Figure <a href="#embedded_lists_1">Non-unique mapping
- containers in the STL's design</a>-B) store equivalent-key
- values in the same bucket, the bucket can be arranged so that
- equivalent-key values are consecutive.</p>
-
- <h6 class="c1"><a name="embedded_lists_1" id=
- "embedded_lists_1"><img src="embedded_lists_1.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Non-unique mapping containers in the STL's
- design.</h6>
-
- <p>Put differently, STL non-unique mapping
- associative-containers are associative containers that map
- primary keys to linked lists that are embedded into the
- container. Figure <a href="#embedded_lists_2">Effect of
- embedded lists in STL multimaps</a> shows again the two
- containers from Figure <a href="#embedded_lists_1">Non-unique
- mapping containers in the STL's design</a>, this time with the
- embedded linked lists of the grayed nodes marked
- explicitly.</p>
-
- <h6 class="c1"><a name="embedded_lists_2" id=
- "embedded_lists_2"><img src="embedded_lists_2.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Effect of embedded lists in STL multimaps.</h6>
-
- <p>These embedded linked lists have several disadvantages.</p>
-
- <ol>
- <li>The underlying data structure embeds the linked lists
- according to its own consideration, which means that the
- search path for a value might include several different
- equivalent-key values. For example, the search path for the
- the black node in either of Figures <a href=
- "#embedded_lists_1">Non-unique mapping containers in the
- STL's design</a> A or B, includes more than a single gray
- node.</li>
-
- <li>The links of the linked lists are the underlying
- data structures' nodes, which typically are quite structured.
- <i>E.g.</i>, in the case of tree-based containers (Figure
- <a href="#embedded_lists_2">Effect of embedded lists in STL
- multimaps</a>-B), each "link" is actually a node with three
- pointers (one to a parent and two to children), and a
- relatively-complicated iteration algorithm. The linked lists,
- therefore, can take up quite a lot of memory, and iterating
- over all values equal to a given key (<i>e.g.</i>, through
- the return value of the STL's <tt>equal_range</tt>) can be
- expensive.</li>
-
- <li>The primary key is stored multiply; this uses more
- memory.</li>
-
- <li>Finally, the interface of this design excludes several
- useful underlying data structures. <i>E.g.</i>, of all the
- unordered self-organizing data structures, practically only
- collision-chaining hash tables can (efficiently) guarantee
- that equivalent-key values are stored consecutively.</li>
- </ol>
-
- <p>The above reasons hold even when the ratio of secondary keys
- to primary keys (or average number of identical keys) is small,
- but when it is large, there are more severe problems:</p>
-
- <ol>
- <li>The underlying data structures order the links inside
- each embedded linked-lists according to their internal
- considerations, which effectively means that each of the
- links is unordered. Irrespective of the underlying
- data structure, searching for a specific value can degrade to
- linear complexity.</li>
-
- <li>Similarly to the above point, it is impossible to apply
- to the secondary keys considerations that apply to primary
- keys. For example, it is not possible to maintain secondary
- keys by sorted order.</li>
-
- <li>While the interface "understands" that all equivalent-key
- values constitute a distinct list (<i>e.g.</i>, through
- <tt>equal_range</tt>), the underlying data structure
- typically does not. This means, <i>e.g.</i>, that operations
- such as erasing from a tree-based container all values whose
- keys are equivalent to a a given key can be super-linear in
- the size of the tree; this is also true also for several
- other operations that target a specific list.</li>
- </ol>
-
- <p>In <tt>pb_ds</tt>, therefore, all associative containers map
- (or store) unique-key values. One can (1) map primary keys to
- secondary associative-containers (<i>i.e.</i>, containers of
- secondary keys) or non-associative containers (2) map identical
- keys to a size-type representing the number of times they
- occur, or (3) any combination of (1) and (2). Instead of
- allowing multiple equivalent-key values, <tt>pb_ds</tt>
- supplies associative containers based on underlying
- data structures that are suitable as secondary
- associative-containers (see <a href=
- "assoc_performance_tests.html#msc">Associative-Container
- Performance Tests::Observations::Mapping-Semantics
- Considerations</a>).</p>
-
- <p>Figures <a href="#embedded_lists_3">Non-unique mapping
- containers in <tt>pb_ds</tt></a> A and B show the equivalent
- structures in <tt>pb_ds</tt>'s design, to those in Figures
- <a href="#embedded_lists_1">Non-unique mapping containers in
- the STL's design</a> A and B, respectively. Each shaded box
- represents some size-type or secondary
- associative-container.</p>
-
- <h6 class="c1"><a name="embedded_lists_3" id=
- "embedded_lists_3"><img src="embedded_lists_3.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Non-unique mapping containers in the
- <tt>pb_ds</tt>.</h6>
-
- <p>In the first example above, then, one would use an
- associative container mapping each user to an associative
- container which maps each application id to a start time (see
- <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_multimap.cc"><tt>basic_multimap.cc</tt></a>);
- in the second example, one would use an associative container
- mapping each <tt><b>int</b></tt> to some size-type indicating
- the number of times it logically occurs (see <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_multiset.cc"><tt>basic_multiset.cc</tt></a>).</p>
-
- <p><a href=
- "assoc_performance_tests.html#multimaps">Associative-Container
- Performance Tests::Multimaps</a> quantifies some of these
- points, and <a href=
- "assoc_performance_tests.html#msc">Associative-Container
- Performance Tests::Observations::Mapping-Semantics
- Considerations</a> shows some simple calculations.</p>
-
- <p><a href="assoc_examples.html#mmaps">Associative-Container
- Examples::Multimaps</a> shows some simple examples of using
- "multimaps".</p>
-
- <p><a href="lu_based_containers.html">Design::Associative
- Containers::List-Based Containers</a> discusses types of
- containers especially suited as secondary
- associative-containers.</p>
-
- <h2><a name="pq" id="pq">Priority Queues</a></h2>
-
- <h3><a name="pq_more_ops" id="pq_more_ops">Slightly Different
- Methods</a></h3>
-
- <p>Priority queues are containers that allow efficiently
- inserting values and accessing the maximal value (in the sense
- of the container's comparison functor); <i>i.e.</i>, their
- interface supports <tt>push</tt> and <tt>pop</tt>. The STL's
- priority queues indeed support these methods, but they support
- little else. For algorithmic and software-engineering purposes,
- other methods are needed:</p>
-
- <ol>
- <li>Many graph algorithms [<a href=
- "references.html#clrs2001">clrs2001</a>] require increasing a
- value in a priority queue (again, in the sense of the
- container's comparison functor), or joining two
- priority-queue objects.</li>
-
- <li>It is sometimes necessary to erase an arbitrary value in
- a priority queue. For example, consider the <tt>select</tt>
- function for monitoring file descriptors:
- <pre>
-<b>int</b>
- select
- (<b>int</b> nfds,
- fd_set *readfds,
- fd_set *writefds,
- fd_set *errorfds,
- <b>struct</b> timeval *timeout);
-</pre>then, as the <tt>select</tt> manual page [<a href=
-"references.html#select_man">select_man</a>] states:
-
- <p><q>The nfds argument specifies the range of file
- descriptors to be tested. The select() function tests file
- descriptors in the range of 0 to nfds-1.</q></p>
-
- <p>It stands to reason, therefore, that we might wish to
- maintain a minimal value for <tt>nfds</tt>, and priority
- queues immediately come to mind. Note, though, that when a
- socket is closed, the minimal file description might
- change; in the absence of an efficient means to erase an
- arbitrary value from a priority queue, we might as well
- avoid its use altogether.</p>
-
- <p><a href="pq_examples.html#xref">Priority-Queue
- Examples::Cross-Referencing</a> shows examples for these
- types of operations.</p>
- </li>
-
- <li>STL containers typically support iterators. It is
- somewhat unusual for <tt>std::priority_queue</tt> to omit
- them (see, <i>e.g.</i>, [<a href=
- "references.html#meyers01stl">meyers01stl</a>]). One might
- ask why do priority queues need to support iterators, since
- they are self-organizing containers with a different purpose
- than abstracting sequences. There are several reasons:
-
- <ol>
- <li>Iterators (even in self-organizing containers) are
- useful for many purposes, <i>e.g.</i>, cross-referencing
- containers, serialization, and debugging code that uses
- these containers.</li>
-
- <li>The STL's hash-based containers support iterators,
- even though they too are self-organizing containers with
- a different purpose than abstracting sequences.</li>
-
- <li>In STL-like containers, it is natural to specify the
- interface of operations for modifying a value or erasing
- a value (discussed previously) in terms of a iterators.
- This is discussed further in <a href=
- "pq_design.html#pq_it">Design::Priority
- Queues::Iterators</a>. It should be noted that the STL's
- containers also use iterators for accessing and
- manipulating a specific value. <i>E.g.</i>, in hash-based
- containers, one checks the existence of a key by
- comparing the iterator returned by <tt>find</tt> to the
- iterator returned by <tt>end</tt>, and not by comparing a
- pointer returned by <tt>find</tt> to <tt>NULL</tt>.</li>
- </ol>
- </li>
- </ol>
-
- <p><a href="pq_performance_tests.html">Performance
- Tests::Priority Queues</a> quantifies some of these points.</p>
-
- <h3><a name="pq_ds_genericity" id="pq_ds_genericity">More Data
- Structures and Traits</a></h3>
-
- <p>There are three main implementations of priority queues: the
- first employs a binary heap, typically one which uses a
- sequence; the second uses a tree (or forest of trees), which is
- typically less structured than an associative container's tree;
- the third simply uses an associative container. These are
- shown, respectively, in Figures <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a> A1 and A2, B, and C.</p>
-
- <h6 class="c1"><a name="pq_different_underlying_dss" id=
- "pq_different_underlying_dss"><img src=
- "pq_different_underlying_dss.png" alt="no image" /></a></h6>
-
- <h6 class="c1">Underlying Priority-Queue Data-Structures.</h6>
-
- <p>No single implementation can completely replace any of the
- others. Some have better <tt>push</tt> and <tt>pop</tt>
- amortized performance, some have better bounded (worst case)
- response time than others, some optimize a single method at the
- expense of others, <i>etc.</i>. In general the "best"
- implementation is dictated by the problem (see <a href=
- "pq_performance_tests.html#pq_observations">Performance
- Tests::Priority Queues::Observations</a>).</p>
-
- <p>As with associative containers (see <a href=
- "#assoc_ds_genericity">Associative Containers::Traits for
- Underlying Data-Structures</a>), the more implementations
- co-exist, the more necessary a traits mechanism is for handling
- generic containers safely and efficiently. This is especially
- important for priority queues, since the invalidation
- guarantees of one of the most useful data structures - binary
- heaps - is markedly different than those of most of the
- others.</p>
-
- <p><a href="pq_design.html#pq_traits">Design::Priority
- Queues::Traits</a> discusses this further.</p>
-
- <h3><a name="pq_binary_heap" id="pq_binary_heap">Binary Heap
- Implementation</a></h3>
-
- <p>Binary heaps are one of the most useful underlying
- data structures for priority queues. They are very efficient in
- terms of memory (since they don't require per-value structure
- metadata), and have the best amortized <tt>push</tt> and
- <tt>pop</tt> performance for primitive types (<i>e.g.</i>,
- <tt><b>int</b></tt>s).</p>
-
- <p>The STL's <tt>priority_queue</tt> implements this data
- structure as an adapter over a sequence, typically
- <tt>std::vector</tt> or <tt>std::deque</tt>, which correspond
- to Figures <a href="#pq_different_underlying_dss">Underlying
- Priority-Queue Data-Structures</a> A1 and A2, respectively.</p>
-
- <p>This is indeed an elegant example of the adapter concept and
- the algorithm/container/iterator decomposition (see [<a href=
- "references.html#nelson96stlpq">nelson96stlpql</a>]). There are
- possibly reasons, however, why a binary-heap priority queue
- would be better implemented as a container instead of a
- sequence adapter:</p>
-
- <ol>
- <li><tt>std::priority_queue</tt> cannot erase values from its
- adapted sequence (irrespective of the sequence type). This
- means that the memory use of an <tt>std::priority_queue</tt>
- object is always proportional to the maximal number of values
- it ever contained, and not to the number of values that it
- currently contains (see <a href=
- "priority_queue_text_pop_mem_usage_test.html">Priority Queue
- Text <tt>pop</tt> Memory Use Test</a>); this implementation
- of binary heaps acts very differently than other underlying
- data structures (<i>e.g.</i>, pairing heaps).</li>
-
- <li>Some combinations of adapted sequences and value types
- are very inefficient or just don't make sense. If one uses
- <tt>std::priority_queue&lt;std::vector&lt;std::string&gt;
- &gt; &gt;</tt>, for example, then not only will each
- operation perform a logarithmic number of
- <tt>std::string</tt> assignments, but, furthermore, any
- operation (including <tt>pop</tt>) can render the container
- useless due to exceptions. Conversely, if one uses
- <tt>std::priority_queue&lt;std::deque&lt;<b>int</b>&gt; &gt;
- &gt;</tt>, then each operation uses incurs a logarithmic
- number of indirect accesses (through pointers) unnecessarily.
- It might be better to let the container make a conservative
- deduction whether to use the structure in Figures <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a> A1 or A2.</li>
-
- <li>There does not seem to be a systematic way to determine
- what exactly can be done with the priority queue.
-
- <ol>
- <li>If <tt>p</tt> is a priority queue adapting an
- <tt>std::vector</tt>, then it is possible to iterate over
- all values by using <tt>&amp;p.top()</tt> and
- <tt>&amp;p.top() + p.size()</tt>, but this will not work
- if <tt>p</tt> is adapting an <tt>std::deque</tt>; in any
- case, one cannot use <tt>p.begin()</tt> and
- <tt>p.end()</tt>. If a different sequence is adapted, it
- is even more difficult to determine what can be
- done.</li>
-
- <li>If <tt>p</tt> is a priority queue adapting an
- <tt>std::deque</tt>, then the reference return by
- <tt>p.top()</tt> will remain valid until it is popped,
- but if <tt>p</tt> adapts an <tt>std::vector</tt>, the
- next <tt>push</tt> will invalidate it. If a different
- sequence is adapted, it is even more difficult to
- determine what can be done.</li>
- </ol>
- </li>
-
- <li>Sequence-based binary heaps can still implement
- linear-time <tt>erase</tt> and <tt>modify</tt> operations.
- This means that if one needs, <i>e.g.</i>, to erase a small
- (say logarithmic) number of values, then one might still
- choose this underlying data structure. Using
- <tt>std::priority_queue</tt>, however, this will generally
- change the order of growth of the entire sequence of
- operations.</li>
- </ol>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/move_to_front_lu_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/move_to_front_lu_policy.html
deleted file mode 100644
index 4ed4d40bd..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/move_to_front_lu_policy.html
+++ /dev/null
@@ -1,194 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>move_to_front_lu_policy Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>move_to_front_lu_policy</tt> Interface</h1>
-
- <p>A list-update policy that unconditionally moves elements to
- the front of the list.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/list_update_policy.hpp"><tt>list_update_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator </a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
-
- <p>This is used only for definitions, e.g., the size
- type.</p>
- </td>
-
- <td>
- <pre>
-std::allocator&lt;<b>char</b>&gt;
-</pre>
- </td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="allocator48440069" id="allocator48440069">allocator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Allocator35940069"><tt>Allocator</tt></a>
-</pre>
- </td>
-
- <td>
- <p><a href="#Allocator35940069"><tt>Allocator</tt></a>
- type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">Metadata-Type
- Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_type2849297114" id=
-"metadata_type2849297114">metadata_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="null_lu_metadata.html"><span class=
-"c2"><tt>null_lu_metadata</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>Metadata on which this functor operates.</p>
-
- <p>In this case, none.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_reference583863863" id=
-"metadata_reference583863863">metadata_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#metadata_type2849297114"><tt>metadata_type</tt></a>&gt;::other::reference
-</pre>
- </td>
-
- <td>
- <p>Reference to metadata on which this functor
- operates.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Public Methods</a></h2>
-
- <h3><a name="link6" id="link6">Metadata Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#metadata_type2849297114"><tt>metadata_type</tt></a>
- <b>operator</b>()
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Creates a metadata object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- <b>operator</b>()
- (<a href=
-"#metadata_reference583863863"><tt>metadata_reference</tt></a> r_metadata) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Decides whether a metadata object should be moved to
- the front of the list.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large.html
deleted file mode 100644
index 74d33a326..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large.html
+++ /dev/null
@@ -1,215 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>"Multimap" Text Find Timing Test with Large Average
- Secondary-Key to Primary-Key Ratio</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>"Multimap" Text Find Timing Test with Large Average
- Secondary-Key to Primary-Key Ratio</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of pairs into a container. The
- first item of each pair is a string from an arbitrary text
- [<a href="references.html#wickland96thirty">wickland96thirty</a>], and
- the second is a uniform i.i.d.integer. The container is a
- "multimap" - it considers the first member of each pair as a
- primary key, and the second member of each pair as a secondary
- key (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Alternative to Multiple Equivalent Keys</a>). There
- are 100 distinct primary keys, and the ratio of secondary keys
- to primary keys ranges to about 20.</p>
-<p>The test measures the average find-time as a function of the
- number of values inserted. For <tt>pb_ds</tt>'s containers, it
- finds the secondary key from a container obtained from finding
- a primary key. For the native multimaps, it searches a range
- obtained using <tt>std::equal_range</tt> on a primary key.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/multimap_text_find_timing_large.cc"><tt>multimap_text_find_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 100 3 4 4)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the find-time scalability of different
- "multimap" designs (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Mapping Semantics</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and
- <a href="#NTL">NTL</a> show the results for "multimaps" which
- use a tree-based container for primary keys, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NHG"></a>NHG, <a href="#NHM">NHM</a>, and <a href="#NHL">NHL</a> show the results for
- "multimaps" which use a hash-based container for primary keys,
- in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>,
- <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>,
- and <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NTG_res_div">
-<div id="NTG_gcc">
-<div id="NTG_multimap_text_find_timing_test_large_s2p_tree">
-<div id="NTG_assoc">
-<div id="NTG_Native_and_primary_tree-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="multimap_text_find_timing_test_large_s2p_tree_gcc.png" alt="no image" /></a></h6>NTG: Native and primary tree-based multimap types find timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_mmap-
-<tt>std::multimap</tt></li>
-<li>
-rb_tree_mmap_lu_mtf_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-<li>
-rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTM_res_div">
-<div id="NTM_msvc">
-<div id="NTM_multimap_text_find_timing_test_large_s2p_tree">
-<div id="NTM_assoc">
-<div id="NTM_Native_and_primary_tree-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="multimap_text_find_timing_test_large_s2p_tree_msvc.png" alt="no image" /></a></h6>NTM: Native and primary tree-based multimap types find timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_mmap-
-<tt>std::multimap</tt></li>
-<li>
-rb_tree_mmap_lu_mtf_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-<li>
-rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTL_res_div">
-<div id="NTL_local">
-<div id="NTL_multimap_text_find_timing_test_large_s2p_tree">
-<div id="NTL_assoc">
-<div id="NTL_Native_and_primary_tree-based_multimap_types_find_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="multimap_text_find_timing_test_large_s2p_tree_local.png" alt="no image" /></a></h6>NTL: Native and primary tree-based multimap types find timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHG_res_div">
-<div id="NHG_gcc">
-<div id="NHG_multimap_text_find_timing_test_large_s2p_hash">
-<div id="NHG_assoc">
-<div id="NHG_Native_and_primary_hash-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="multimap_text_find_timing_test_large_s2p_hash_gcc.png" alt="no image" /></a></h6>NHG: Native and primary hash-based multimap types find timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_mmap-
-<tt>__gnucxx::hash_multimap</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHM_res_div">
-<div id="NHM_msvc">
-<div id="NHM_multimap_text_find_timing_test_large_s2p_hash">
-<div id="NHM_assoc">
-<div id="NHM_Native_and_primary_hash-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="multimap_text_find_timing_test_large_s2p_hash_msvc.png" alt="no image" /></a></h6>NHM: Native and primary hash-based multimap types find timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_mmap-
-<tt>stdext::hash_multimap</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHL_res_div">
-<div id="NHL_local">
-<div id="NHL_multimap_text_find_timing_test_large_s2p_hash">
-<div id="NHL_assoc">
-<div id="NHL__Native_and_primary_hash-based_multimap_types_find_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="multimap_text_find_timing_test_large_s2p_hash_local.png" alt="no image" /></a></h6>NHL: Native and primary hash-based multimap types find timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>See <a href="assoc_performance_tests.html#msc">Observations::Mapping-Semantics
- Considerations</a>.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_gcc.png
deleted file mode 100644
index 03a62f52b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_local.png
deleted file mode 100644
index 32a61cac9..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_msvc.png
deleted file mode 100644
index 4462d289a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_hash_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_gcc.png
deleted file mode 100644
index 89e464481..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_local.png
deleted file mode 100644
index 10b3980ed..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_msvc.png
deleted file mode 100644
index 20320953e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_large_s2p_tree_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small.html
deleted file mode 100644
index 1b379d821..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small.html
+++ /dev/null
@@ -1,215 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>"Multimap" Text Find Timing Test with Small Average
- Secondary-Key to Primary-Key Ratio</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>"Multimap" Text Find Timing Test with Small Average
- Secondary-Key to Primary-Key Ratio</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of pairs into a container. The
- first item of each pair is a string from an arbitrary text
- [<a href="references.html#wickland96thirty">wickland96thirty</a>], and
- the second is a uniform i.i.d.integer. The container is a
- "multimap" - it considers the first member of each pair as a
- primary key, and the second member of each pair as a secondary
- key (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Alternative to Multiple Equivalent Keys</a>). There
- are 400 distinct primary keys, and the ratio of secondary keys
- to primary keys ranges from 1 to 5.</p>
-<p>The test measures the average find-time as a function of the
- number of values inserted. For <tt>pb_ds</tt>'s containers, it
- finds the secondary key from a container obtained from finding
- a primary key. For the native multimaps, it searches a range
- obtained using <tt>std::equal_range</tt> on a primary key.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/multimap_text_find_timing_small.cc"><tt>multimap_text_find_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 400 1 1 6)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the find-time scalability of different
- "multimap" designs (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Mapping Semantics</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and
- <a href="#NTL">NTL</a> show the results for "multimaps" which
- use a tree-based container for primary keys, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NHG"></a>NHG, <a href="#NHM">NHM</a>, and <a href="#NHL">NHL</a> show the results for
- "multimaps" which use a hash-based container for primary keys,
- in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>,
- <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>,
- and <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NTG_res_div">
-<div id="NTG_gcc">
-<div id="NTG_multimap_text_find_timing_test_small_s2p_tree">
-<div id="NTG_assoc">
-<div id="NHG_Native_and_primary_tree-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="multimap_text_find_timing_test_small_s2p_tree_gcc.png" alt="no image" /></a></h6>NTG: NHG Native and primary tree-based multimap types find timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_mmap-
-<tt>std::multimap</tt></li>
-<li>
-rb_tree_mmap_lu_mtf_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-<li>
-rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTM_res_div">
-<div id="NTM_msvc">
-<div id="NTM_multimap_text_find_timing_test_small_s2p_tree">
-<div id="NTM_assoc">
-<div id="NHM_Native_and_primary_tree-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="multimap_text_find_timing_test_small_s2p_tree_msvc.png" alt="no image" /></a></h6>NTM: NHM Native and primary tree-based multimap types find timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_mmap-
-<tt>std::multimap</tt></li>
-<li>
-rb_tree_mmap_lu_mtf_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-<li>
-rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTL_res_div">
-<div id="NTL_local">
-<div id="NTL_multimap_text_find_timing_test_small_s2p_tree">
-<div id="NTL_assoc">
-<div id="NTL_Native_and_primary_tree-based_multimap_types_find_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="multimap_text_find_timing_test_small_s2p_tree_local.png" alt="no image" /></a></h6>NTL: Native and primary tree-based multimap types find timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHG_res_div">
-<div id="NHG_gcc">
-<div id="NHG_multimap_text_find_timing_test_small_s2p_hash">
-<div id="NHG_assoc">
-<div id="NHG_Native_and_primary_hash-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="multimap_text_find_timing_test_small_s2p_hash_gcc.png" alt="no image" /></a></h6>NHG: Native and primary hash-based multimap types find timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_mmap-
-<tt>__gnucxx::hash_multimap</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHM_res_div">
-<div id="NHM_msvc">
-<div id="NHM_multimap_text_find_timing_test_small_s2p_hash">
-<div id="NHM_assoc">
-<div id="NHM_Native_and_primary_hash-based_multimap_types_find_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="multimap_text_find_timing_test_small_s2p_hash_msvc.png" alt="no image" /></a></h6>NHM: Native and primary hash-based multimap types find timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_mmap-
-<tt>stdext::hash_multimap</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHL_res_div">
-<div id="NHL_local">
-<div id="NHL_multimap_text_find_timing_test_small_s2p_hash">
-<div id="NHL_assoc">
-<div id="NHL__Native_and_primary_hash-based_multimap_types_find_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="multimap_text_find_timing_test_small_s2p_hash_local.png" alt="no image" /></a></h6>NHL: Native and primary hash-based multimap types find timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>See <a href="assoc_performance_tests.html#msc">Observations::Mapping-Semantics
- Considerations</a>.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_gcc.png
deleted file mode 100644
index 60e850937..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_local.png
deleted file mode 100644
index a8fa26117..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_msvc.png
deleted file mode 100644
index 11aa9e07b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_hash_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_gcc.png
deleted file mode 100644
index f54369b15..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_local.png
deleted file mode 100644
index b3d10612f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_msvc.png
deleted file mode 100644
index 035fd9389..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_find_timing_test_small_s2p_tree_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html
deleted file mode 100644
index 4affbf440..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large.html
+++ /dev/null
@@ -1,210 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Hash-List "Multimap" Text Memory Use Test with Large
- Average Secondary-Key to Primary-Key Ratio</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>"Multimap" Text Memory Use Test with Large Average
- Secondary-Key to Primary-Key Ratio</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of pairs into a container. The
- first item of each pair is a string from an arbitrary text
- [<a href="references.html#wickland96thirty">wickland96thirty</a>], and
- the second is a uniform i.i.d.integer. The container is a
- "multimap" - it considers the first member of each pair as a
- primary key, and the second member of each pair as a secondary
- key (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Alternative to Multiple Equivalent Keys</a>). There
- are 100 distinct primary keys. The test measures the memory use
- as a function of the number of values inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/multimap_text_insert_mem_usage_large.cc"><tt>multimap_text_insert_mem_usage_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 100 200 2100 100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the memory scalability of different
- "multimap" designs (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Mapping Semantics</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and
- <a href="#NTL">NTL</a> show the results for "multimaps" which
- use a tree-based container for primary keys, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NHG"></a>NHG, <a href="#NHM">NHM</a>, and <a href="#NHL">NHL</a> show the results for
- "multimaps" which use a hash-based container for primary keys,
- in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>,
- <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>,
- and <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NTG_res_div">
-<div id="NTG_gcc">
-<div id="NTG_multimap_text_insert_mem_usage_test_large_s2p_tree">
-<div id="NTG_assoc">
-<div id="NHG_Native_and_primary_tree-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.png" alt="no image" /></a></h6>NTG: NHG Native and primary tree-based multimap types mem usage test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-n_mmap-
-<tt>std::multimap</tt></li>
-<li>
-rb_tree_mmap_lu_mtf_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTM_res_div">
-<div id="NTM_msvc">
-<div id="NTM_multimap_text_insert_mem_usage_test_large_s2p_tree">
-<div id="NTM_assoc">
-<div id="NHM_Native_and_primary_tree-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.png" alt="no image" /></a></h6>NTM: NHM Native and primary tree-based multimap types mem usage test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_mmap-
-<tt>std::multimap</tt></li>
-<li>
-rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-rb_tree_mmap_lu_mtf_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTL_res_div">
-<div id="NTL_local">
-<div id="NTL_multimap_text_insert_mem_usage_test_large_s2p_tree">
-<div id="NTL_assoc">
-<div id="NTL_Native_and_primary_tree-based_multimap_types_mem_usage_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="multimap_text_insert_mem_usage_test_large_s2p_tree_local.png" alt="no image" /></a></h6>NTL: Native and primary tree-based multimap types mem usage test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHG_res_div">
-<div id="NHG_gcc">
-<div id="NHG_multimap_text_insert_mem_usage_test_large_s2p_hash">
-<div id="NHG_assoc">
-<div id="NHG_Native_and_primary_hash-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.png" alt="no image" /></a></h6>NHG: Native and primary hash-based multimap types mem usage test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-n_hash_mmap-
-<tt>__gnucxx::hash_multimap</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHM_res_div">
-<div id="NHM_msvc">
-<div id="NHM_multimap_text_insert_mem_usage_test_large_s2p_hash">
-<div id="NHM_assoc">
-<div id="NHM_Native_and_primary_hash-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.png" alt="no image" /></a></h6>NHM: Native and primary hash-based multimap types mem usage test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_mmap-
-<tt>stdext::hash_multimap</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHL_res_div">
-<div id="NHL_local">
-<div id="NHL_multimap_text_insert_mem_usage_test_large_s2p_hash">
-<div id="NHL_assoc">
-<div id="NHL__Native_and_primary_hash-based_multimap_types_mem_usage_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="multimap_text_insert_mem_usage_test_large_s2p_hash_local.png" alt="no image" /></a></h6>NHL: Native and primary hash-based multimap types mem usage test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>See <a href="assoc_performance_tests.html#msc">Observations::Mapping-Semantics
- Considerations</a>.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.png
deleted file mode 100644
index 51a3f8d61..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_local.png
deleted file mode 100644
index 8af7100c6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.png
deleted file mode 100644
index 3a938c0bb..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_hash_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.png
deleted file mode 100644
index a992d8f7c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_local.png
deleted file mode 100644
index 63c0c8db7..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.png
deleted file mode 100644
index 26841bd10..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_large_s2p_tree_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html
deleted file mode 100644
index 462fce4ca..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small.html
+++ /dev/null
@@ -1,212 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Hash-List "Multimap" Text Memory Use Test with Small
- Average Secondary-Key to Primary-Key Ratio</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>"Multimap" Text Memory Use Test with Small Average
- Secondary-Key to Primary-Key Ratio</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of pairs into a container. The
- first item of each pair is a string from an arbitrary text
- [<a href="references.html#wickland96thirty">wickland96thirty</a>], and
- the second is a uniform i.i.d.integer. The container is a
- "multimap" - it considers the first member of each pair as a
- primary key, and the second member of each pair as a secondary
- key (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Alternative to Multiple Equivalent Keys</a>). There
- are 100 distinct primary keys, and the ratio of secondary keys
- to primary keys ranges to about 20.</p>
-<p>The test measures the memory use as a function of the number
- of values inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/multimap_text_insert_mem_usage_small.cc"><tt>multimap_text_insert_mem_usage_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 100 3 4 4)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the memory scalability of different
- "multimap" designs (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Mapping Semantics</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and
- <a href="#NTL">NTL</a> show the results for "multimaps" which
- use a tree-based container for primary keys, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NHG"></a>NHG, <a href="#NHM">NHM</a>, and <a href="#NHL">NHL</a> show the results for
- "multimaps" which use a hash-based container for primary keys,
- in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>,
- <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>,
- and <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NTG_res_div">
-<div id="NTG_gcc">
-<div id="NTG_multimap_text_insert_mem_usage_test_small_s2p_tree">
-<div id="NTG_assoc">
-<div id="NTG_Native_and_primary_tree-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="multimap_text_insert_mem_usage_test_small_s2p_tree_gcc.png" alt="no image" /></a></h6>NTG: Native and primary tree-based multimap types mem usage test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-n_mmap-
-<tt>std::multimap</tt></li>
-<li>
-rb_tree_mmap_lu_mtf_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTM_res_div">
-<div id="NTM_msvc">
-<div id="NTM_multimap_text_insert_mem_usage_test_small_s2p_tree">
-<div id="NTM_assoc">
-<div id="NHM_Native_and_primary_tree-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="multimap_text_insert_mem_usage_test_small_s2p_tree_msvc.png" alt="no image" /></a></h6>NTM: NHM Native and primary tree-based multimap types mem usage test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-n_mmap-
-<tt>std::multimap</tt></li>
-<li>
-rb_tree_mmap_lu_mtf_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTL_res_div">
-<div id="NTL_local">
-<div id="NTL_multimap_text_insert_mem_usage_test_small_s2p_tree">
-<div id="NTL_assoc">
-<div id="NTL_Native_and_primary_tree-based_multimap_types_mem_usage_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="multimap_text_insert_mem_usage_test_small_s2p_tree_local.png" alt="no image" /></a></h6>NTL: Native and primary tree-based multimap types mem usage test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHG_res_div">
-<div id="NHG_gcc">
-<div id="NHG_multimap_text_insert_mem_usage_test_small_s2p_hash">
-<div id="NHG_assoc">
-<div id="NHG_Native_and_primary_hash-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="multimap_text_insert_mem_usage_test_small_s2p_hash_gcc.png" alt="no image" /></a></h6>NHG: Native and primary hash-based multimap types mem usage test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-n_hash_mmap-
-<tt>__gnucxx::hash_multimap</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHM_res_div">
-<div id="NHM_msvc">
-<div id="NHM_multimap_text_insert_mem_usage_test_small_s2p_hash">
-<div id="NHM_assoc">
-<div id="NHM_Native_and_primary_hash-based_multimap_types_mem_usage_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="multimap_text_insert_mem_usage_test_small_s2p_hash_msvc.png" alt="no image" /></a></h6>NHM: Native and primary hash-based multimap types mem usage test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-n_hash_mmap-
-<tt>stdext::hash_multimap</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHL_res_div">
-<div id="NHL_local">
-<div id="NHL_multimap_text_insert_mem_usage_test_small_s2p_hash">
-<div id="NHL_assoc">
-<div id="NHL__Native_and_primary_hash-based_multimap_types_mem_usage_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="multimap_text_insert_mem_usage_test_small_s2p_hash_local.png" alt="no image" /></a></h6>NHL: Native and primary hash-based multimap types mem usage test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>See <a href="assoc_performance_tests.html#msc">Observations::Mapping-Semantics
- Considerations</a>.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_gcc.png
deleted file mode 100644
index d3eba9da4..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_local.png
deleted file mode 100644
index 589dccdef..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_msvc.png
deleted file mode 100644
index 1828896ee..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_hash_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_gcc.png
deleted file mode 100644
index 9334bc35b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_local.png
deleted file mode 100644
index d7322f287..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_msvc.png
deleted file mode 100644
index 2f20e57e5..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_mem_usage_test_small_s2p_tree_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large.html
deleted file mode 100644
index b9a2d9952..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large.html
+++ /dev/null
@@ -1,212 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>"Multimap" Text Insert Timing Test with Large Average
- Secondary-Key to Primary-Key Ratio</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>"Multimap" Text Insert Timing Test with Large Average
- Secondary-Key to Primary-Key Ratio</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of pairs into a container. The
- first item of each pair is a string from an arbitrary text
- [<a href="references.html#wickland96thirty">wickland96thirty</a>], and
- the second is a uniform i.i.d.integer. The container is a
- "multimap" - it considers the first member of each pair as a
- primary key, and the second member of each pair as a secondary
- key (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Alternative to Multiple Equivalent Keys</a>). There
- are 100 distinct primary keys, and the ratio of secondary keys
- to primary keys ranges to about 20.</p>
-<p>The test measures the memory use as a function of the number
- of values inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/multimap_text_insert_mem_usage_large.cc"><tt>multimap_text_insert_mem_usage_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 400 1 6 6)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the insert-time scalability of different
- "multimap" designs (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Mapping Semantics</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and
- <a href="#NTL">NTL</a> show the results for "multimaps" which
- use a tree-based container for primary keys, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NHG"></a>NHG, <a href="#NHM">NHM</a>, and <a href="#NHL">NHL</a> show the results for
- "multimaps" which use a hash-based container for primary keys,
- in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>,
- <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>,
- and <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NTG_res_div">
-<div id="NTG_gcc">
-<div id="NTG_multimap_text_insert_timing_test_large_s2p_tree">
-<div id="NTG_assoc">
-<div id="NTG_Native_and_primary_tree-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="multimap_text_insert_timing_test_large_s2p_tree_gcc.png" alt="no image" /></a></h6>NTG: Native and primary tree-based multimap types insert timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_mmap-
-<tt>std::multimap</tt></li>
-<li>
-rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-rb_tree_mmap_lu_mtf_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTM_res_div">
-<div id="NTM_msvc">
-<div id="NTM_multimap_text_insert_timing_test_large_s2p_tree">
-<div id="NTM_assoc">
-<div id="NHM_Native_and_primary_tree-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="multimap_text_insert_timing_test_large_s2p_tree_msvc.png" alt="no image" /></a></h6>NTM: NHM Native and primary tree-based multimap types insert timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-n_mmap-
-<tt>std::multimap</tt></li>
-<li>
-rb_tree_mmap_lu_mtf_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTL_res_div">
-<div id="NTL_local">
-<div id="NTL_multimap_text_insert_timing_test_large_s2p_tree">
-<div id="NTL_assoc">
-<div id="NTL_Native_and_primary_tree-based_multimap_types_insert_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="multimap_text_insert_timing_test_large_s2p_tree_local.png" alt="no image" /></a></h6>NTL: Native and primary tree-based multimap types insert timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHG_res_div">
-<div id="NHG_gcc">
-<div id="NHG_multimap_text_insert_timing_test_large_s2p_hash">
-<div id="NHG_assoc">
-<div id="NHG_Native_and_primary_hash-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="multimap_text_insert_timing_test_large_s2p_hash_gcc.png" alt="no image" /></a></h6>NHG: Native and primary hash-based multimap types insert timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_mmap-
-<tt>__gnucxx::hash_multimap</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHM_res_div">
-<div id="NHM_msvc">
-<div id="NHM_multimap_text_insert_timing_test_large_s2p_hash">
-<div id="NHM_assoc">
-<div id="NHM_Native_and_primary_hash-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="multimap_text_insert_timing_test_large_s2p_hash_msvc.png" alt="no image" /></a></h6>NHM: Native and primary hash-based multimap types insert timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_mmap-
-<tt>stdext::hash_multimap</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHL_res_div">
-<div id="NHL_local">
-<div id="NHL_multimap_text_insert_timing_test_large_s2p_hash">
-<div id="NHL_assoc">
-<div id="NHL__Native_and_primary_hash-based_multimap_types_insert_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="multimap_text_insert_timing_test_large_s2p_hash_local.png" alt="no image" /></a></h6>NHL: Native and primary hash-based multimap types insert timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>See <a href="assoc_performance_tests.html#msc">Observations::Mapping-Semantics
- Considerations</a>.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_gcc.png
deleted file mode 100644
index 55b0bf467..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_local.png
deleted file mode 100644
index 5f8946008..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_msvc.png
deleted file mode 100644
index 02f5d0b20..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_hash_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_gcc.png
deleted file mode 100644
index 83366eb37..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_local.png
deleted file mode 100644
index 2b496b48d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_msvc.png
deleted file mode 100644
index 47196bff7..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_large_s2p_tree_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small.html
deleted file mode 100644
index cda3629b7..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small.html
+++ /dev/null
@@ -1,217 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>"Multimap" Text Insert Timing Test with Small Average
- Secondary-Key to Primary-Key Ratio</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>"Multimap" Text Insert Timing Test with Small Average
- Secondary-Key to Primary-Key Ratio</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of pairs into a container. The
- first item of each pair is a string from an arbitrary text
- [<a href="references.html#wickland96thirty">wickland96thirty</a>], and
- the second is a uniform i.i.d.integer. The container is a
- "multimap" - it considers the first member of each pair as a
- primary key, and the second member of each pair as a secondary
- key (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Alternative to Multiple Equivalent Keys</a>). There
- are 400 distinct primary keys, and the ratio of secondary keys
- to primary keys ranges from 1 to 5.</p>
-<p>The test measures the average insert-time as a function of
- the number of values inserted. For <tt>pb_ds</tt>'s containers,
- it inserts a primary key into the primary associative
- container, then a secondary key into the secondary associative
- container. For the native multimaps, it obtains a range using
- <tt>std::equal_range</tt>, and inserts a value only if it was
- not contained already.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/multimap_text_insert_timing_small.cc"><tt>multimap_text_insert_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 400 1 1 6)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the insert-time scalability of different
- "multimap" designs (see <a href="motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Alternative to Multiple Equivalent Keys</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and
- <a href="#NTL">NTL</a> show the results for "multimaps" which
- use a tree-based container for primary keys, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NHG"></a>NHG, <a href="#NHM">NHM</a>, and <a href="#NHL">NHL</a> show the results for
- "multimaps" which use a hash-based container for primary keys,
- in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>,
- <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>,
- and <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NTG_res_div">
-<div id="NTG_gcc">
-<div id="NTG_multimap_text_insert_timing_test_small_s2p_tree">
-<div id="NTG_assoc">
-<div id="NTG_Native_and_primary_tree-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="multimap_text_insert_timing_test_small_s2p_tree_gcc.png" alt="no image" /></a></h6>NTG: Native and primary tree-based multimap types insert timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_mmap-
-<tt>std::multimap</tt></li>
-<li>
-rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-rb_tree_mmap_lu_mtf_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTM_res_div">
-<div id="NTM_msvc">
-<div id="NTM_multimap_text_insert_timing_test_small_s2p_tree">
-<div id="NTM_assoc">
-<div id="NHM_Native_and_primary_tree-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="multimap_text_insert_timing_test_small_s2p_tree_msvc.png" alt="no image" /></a></h6>NTM: NHM Native and primary tree-based multimap types insert timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-rb_tree_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-n_mmap-
-<tt>std::multimap</tt></li>
-<li>
-rb_tree_mmap_lu_mtf_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTL_res_div">
-<div id="NTL_local">
-<div id="NTL_multimap_text_insert_timing_test_small_s2p_tree">
-<div id="NTL_assoc">
-<div id="NTL_Native_and_primary_tree-based_multimap_types_insert_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="multimap_text_insert_timing_test_small_s2p_tree_local.png" alt="no image" /></a></h6>NTL: Native and primary tree-based multimap types insert timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHG_res_div">
-<div id="NHG_gcc">
-<div id="NHG_multimap_text_insert_timing_test_small_s2p_hash">
-<div id="NHG_assoc">
-<div id="NHG_Native_and_primary_hash-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHG" id="NHG"><img src="multimap_text_insert_timing_test_small_s2p_hash_gcc.png" alt="no image" /></a></h6>NHG: Native and primary hash-based multimap types insert timing test - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_hash_mmap-
-<tt>__gnucxx::hash_multimap</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHM_res_div">
-<div id="NHM_msvc">
-<div id="NHM_multimap_text_insert_timing_test_small_s2p_hash">
-<div id="NHM_assoc">
-<div id="NHM_Native_and_primary_hash-based_multimap_types_insert_timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHM" id="NHM"><img src="multimap_text_insert_timing_test_small_s2p_hash_msvc.png" alt="no image" /></a></h6>NHM: Native and primary hash-based multimap types insert timing test - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i></li>
-<li>
-n_hash_mmap-
-<tt>stdext::hash_multimap</tt></li>
-<li>
-cc_hash_mask_exp_nea_lc_1div8_1div2_nsth_mmap_lu_mtf_set-
-<a href="cc_hash_table.html"><tt>cc_hash_table</tt></a>
-with <tt>Comb_Hash_Fn</tt> = <a href="direct_mask_range_hashing.html"><tt>direct_mask_range_hashing</tt></a>
-, and <tt>Resize_Policy</tt> = <a href="hash_standard_resize_policy.html"><tt>hash_standard_resize_policy</tt></a>
- with <tt>Size_Policy</tt> = <a href="hash_exponential_size_policy.html"><tt>hash_exponential_size_policy</tt></a>
-, and <tt>Trigger_Policy</tt> = <a href="hash_load_check_resize_trigger.html"><tt>hash_load_check_resize_trigger</tt></a>
- with <i>&alpha;<sub>min</sub></i> = <i>1/8</i> and <i>&alpha;<sub>max</sub></i> = <i>1/2</i>, mapping each key to <a href="list_update.html"><tt>list_update</tt></a>
- with <tt>Update_Policy</tt> = <a href="move_to_front_lu_policy.html"><tt>move_to_front_lu_policy</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NHL_res_div">
-<div id="NHL_local">
-<div id="NHL_multimap_text_insert_timing_test_small_s2p_hash">
-<div id="NHL_assoc">
-<div id="NHL_Native_and_primary_hash-based_multimap_types_insert_timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NHL" id= "NHL"><img src="multimap_text_insert_timing_test_small_s2p_hash_local.png" alt="no image" /></a></h6>NHL: Native and primary hash-based multimap types insert timing test - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>See <a href="assoc_performance_tests.html#msc">Observations::Mapping-Semantics
- Considerations</a>.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_gcc.png
deleted file mode 100644
index 3c2d87ecf..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_local.png
deleted file mode 100644
index 4af78faa5..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_msvc.png
deleted file mode 100644
index 81d583904..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_hash_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_gcc.png
deleted file mode 100644
index 368f07350..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_local.png
deleted file mode 100644
index 40b5b2c43..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_msvc.png
deleted file mode 100644
index 99f2d690f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/multimap_text_insert_timing_test_small_s2p_tree_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariant_invalidations.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariant_invalidations.png
deleted file mode 100644
index bbd91842b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariant_invalidations.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariants.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariants.png
deleted file mode 100644
index b375f5168..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/node_invariants.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_hash_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_hash_fn.html
deleted file mode 100644
index 34f1ee06a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_hash_fn.html
+++ /dev/null
@@ -1,32 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>null_hash_fn Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>null_hash_fn</tt> Interface</h1>
-
- <p>A "null" hash function, indicating that the combining hash
- function is actually a ranged hash function.</p>
-
- <p><a href=
- "concepts.html#concepts_null_policies">Interface::Concepts::Null
- Policy Classes</a> explains the concept of a null policy. See
- also <a href=
- "hash_based_containers.html#hash_policies">Design::Hash-Based
- Containers::Hash Policies</a>.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_lu_metadata.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_lu_metadata.html
deleted file mode 100644
index e8fb6a3c8..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_lu_metadata.html
+++ /dev/null
@@ -1,25 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>null_lu_metadata Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>null_lu_metadata</tt> Interface</h1>
-
- <p>A null type that means that each link in a list-based
- container does not actually need metadata.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/list_update_policy.hpp"><tt>list_update_policy.hpp</tt></a></p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_mapped_type.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_mapped_type.html
deleted file mode 100644
index d62fac5c9..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_mapped_type.html
+++ /dev/null
@@ -1,25 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>null_mapped_type Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>null_mapped_type</tt> Interface</h1>
-
- <p>A mapped-policy indicating that an associative container is
- a "set"</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_probe_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_probe_fn.html
deleted file mode 100644
index 1c8811e96..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_probe_fn.html
+++ /dev/null
@@ -1,29 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>null_probe_fn Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>null_probe_fn</tt> Interface</h1>
-
- <p>A "null" probe function, indicating that the combining probe
- function is actually a ranged probe function.</p>
-
- <p><a href=
- "concepts.html#concepts_null_policies">Interface::Concepts::Null
- Policy Classes</a> explains the concept of a null policy.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_tree_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_tree_node_update.html
deleted file mode 100644
index cc1c90054..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_tree_node_update.html
+++ /dev/null
@@ -1,101 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>null_tree_node_update Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>null_tree_node_update</tt> Interface</h1>
-
- <p>A "null" node updater, indicating that no node updates are
- required.</p>
-
- <p><a href=
- "concepts.html#concepts_null_policies">Interface::Concepts::Null
- Policy Classes</a> explains the concept of a null policy.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tree_policy.hpp"><tt>tree_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Const_Node_Iterator1933878761" id=
-"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Const node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Node_Iterator4206909839" id=
-"Node_Iterator4206909839"><b>class</b> Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Cmp_Fn294335" id="Cmp_Fn294335"><b>class</b> Cmp_Fn</a>
-</pre>
- </td>
-
- <td>
- <p>Comparison functor.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator</a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>-</td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_trie_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_trie_node_update.html
deleted file mode 100644
index 18ea00739..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/null_trie_node_update.html
+++ /dev/null
@@ -1,102 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>null_trie_node_update Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>null_trie_node_update</tt> Interface</h1>
-
- <p>A "null" node updater, indicating that no node updates are
- required.</p>
-
- <p><a href=
- "concepts.html#concepts_null_policies">Interface::Concepts::Null
- Policy Classes</a> explains the concept of a null policy.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/trie_policy.hpp"><tt>trie_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Const_Node_Iterator1933878761" id=
-"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Const node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Node_Iterator4206909839" id=
-"Node_Iterator4206909839"><b>class</b> Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="E_Access_Traits686553840" id=
-"E_Access_Traits686553840"><b>class</b> E_Access_Traits</a>
-</pre>
- </td>
-
- <td>
- <p>Comparison functor.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator</a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>-</td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ov_tree_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ov_tree_tag.html
deleted file mode 100644
index 01d7f9082..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/ov_tree_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>ov_tree_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>ov_tree_tag</tt> Interface</h1>
-
- <p>Ordered-vector tree data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="tree_tag.html"><span class=
-"c2"><tt>tree_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_heap_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_heap_tag.html
deleted file mode 100644
index 5901d1a88..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_heap_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>pairing_heap_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>pairing_heap_tag</tt> Interface</h1>
-
- <p>Pairing-heap data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="priority_queue_tag.html"><span class=
-"c2"><tt>priority_queue_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_gcc.png
deleted file mode 100644
index 4168787ec..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_local.png
deleted file mode 100644
index 97ca4e9da..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_msvc.png
deleted file mode 100644
index 42b707965..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_pop_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_gcc.png
deleted file mode 100644
index 9a7ce6c36..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_local.png
deleted file mode 100644
index cedcb4cf4..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_msvc.png
deleted file mode 100644
index d5488efcf..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pairing_priority_queue_text_push_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie.png
deleted file mode 100644
index e7129a1a6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie_tag.html
deleted file mode 100644
index 2e9a32c91..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pat_trie_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>pat_trie_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>pat_trie_tag</tt> Interface</h1>
-
- <p>PATRICIA trie data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="tree_tag.html"><span class=
-"c2"><tt>tree_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_invalidation_guarantee.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_invalidation_guarantee.html
deleted file mode 100644
index f67722169..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_invalidation_guarantee.html
+++ /dev/null
@@ -1,51 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>point_invalidation_guarantee Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>point_invalidation_guarantee</tt> Interface</h1>
-
- <p>Signifies an invalidation guarantee that includes all those
- of its base, and additionally, that any point-type iterator,
- pointer, or reference to a container object's mapped value type
- is valid as long as its corresponding entry has not be erased,
- regardless of modifications to the container object.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="basic_invalidation_guarantee.html"><span class=
-"c2"><tt>basic_invalidation_guarantee</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_cd.png
deleted file mode 100644
index 25a69fc6e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_cd.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_1.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_1.png
deleted file mode 100644
index c5bc8e5d6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_1.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_2.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_2.png
deleted file mode 100644
index c3f94ee93..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/point_iterators_range_ops_2.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_container_traits.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_container_traits.html
deleted file mode 100644
index dcd995f5f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_container_traits.html
+++ /dev/null
@@ -1,132 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>container_traits Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>container_traits</tt> Interface</h1>
-
- <p>Traits of a priority-queue container based on its underlying
- data structure.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Cntnr59189" id="Cntnr59189"><b>class</b> Cntnr</a>
-</pre>
- </td>
-
- <td>
- <p>Container type.</p>
- </td>
-
- <td>-</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">Container Attributes</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="container_category1247973216" id=
-"container_category1247973216">container_category</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Underlying data structure.
-</pre>
- </td>
-
- <td>
- <p>Data structure category.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="invalidation_guarantee3793555937" id=
-"invalidation_guarantee3793555937">invalidation_guarantee</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Invalidation guarantee.
-</pre>
- </td>
-
- <td>
- <p>Invalidation-guarantee type.</p>
-
- <p>This is either <a href=
- "basic_invalidation_guarantee.html"><span class=
- "c2"><tt>basic_invalidation_guarantee</tt></span></a>,
- <a href="point_invalidation_guarantee.html"><span class=
- "c2"><tt>point_invalidation_guarantee</tt></span></a>, or
- <a href="range_invalidation_guarantee.html"><span class=
- "c2"><tt>range_invalidation_guarantee</tt></span></a></p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="split_join_can_throw3200477759" id=
-"split_join_can_throw3200477759">split_join_can_throw</a>
-</pre>
- </td>
-
- <td>
- <pre>
-True only if split or join operations can throw.
-</pre>
- </td>
-
- <td>
- <p>Split-join throw indicator.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_design.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_design.html
deleted file mode 100644
index 959560045..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_design.html
+++ /dev/null
@@ -1,381 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Priority-Queues</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Priority-Queue Design</h1>
-
- <h2><a name="overview" id="overview">Overview</a></h2>
-
- <p>The priority-queue container has the following
- declaration:</p>
- <pre>
-<b>template</b>&lt;
- <b>typename</b> Value_Type,
- <b>typename</b> Cmp_Fn = std::less&lt;Value_Type&gt;,
- <b>typename</b> Tag = <a href="pairing_heap_tag.html">pairing_heap_tag</a>,
- <b>typename</b> Allocator = std::allocator&lt;<b>char</b>&gt; &gt;
-<b>class</b> <a href="priority_queue.html">priority_queue</a>;
-</pre>
-
- <p>The parameters have the following meaning:</p>
-
- <ol>
- <li><tt>Value_Type</tt> is the value type.</li>
-
- <li><tt>Cmp_Fn</tt> is a value comparison functor</li>
-
- <li><tt>Tag</tt> specifies which underlying data structure
- to use.</li>
-
- <li><tt>Allocator</tt> is an allocator
- type.</li>
- </ol>
-
- <p>The <tt>Tag</tt> parameter specifies which underlying
- data structure to use. Instantiating it by <a href=
- "pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>,
- <a href=
- "binary_heap_tag.html"><tt>binary_heap_tag</tt></a>,
- <a href=
- "binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>,
- <a href=
- "rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>,
- or <a href=
- "thin_heap_tag.html"><tt>thin_heap_tag</tt></a>,
- specifies, respectively, an underlying pairing heap [<a href=
- "references.html#fredman86pairing">fredman86pairing</a>],
- binary heap [<a href="references.html#clrs2001">clrs2001</a>],
- binomial heap [<a href=
- "references.html#clrs2001">clrs2001</a>], a binomial heap with
- a redundant binary counter [<a href=
- "references.html#maverik_lowerbounds">maverik_lowerbounds</a>],
- or a thin heap [<a href=
- "references.html#kt99fat_heaps">kt99fat_heas</a>]. These are
- explained further in <a href="#pq_imp">Implementations</a>.</p>
-
- <p>As mentioned in <a href=
- "tutorial.html#pq">Tutorial::Priority Queues</a>,
- <a href=
- "priority_queue.html"><tt>__gnu_pbds::priority_queue</tt></a>
- shares most of the same interface with <tt>std::priority_queue</tt>.
- <i>E.g.</i> if <tt>q</tt> is a priority queue of type
- <tt>Q</tt>, then <tt>q.top()</tt> will return the "largest"
- value in the container (according to <tt><b>typename</b>
- Q::cmp_fn</tt>). <a href=
- "priority_queue.html"><tt>__gnu_pbds::priority_queue</tt></a>
- has a larger (and very slightly different) interface than
- <tt>std::priority_queue</tt>, however, since typically
- <tt>push</tt> and <tt>pop</tt> are deemed insufficient for
- manipulating priority-queues. </p>
-
- <p>Different settings require different priority-queue
- implementations which are described in <a href=
- "#pq_imp">Implementations</a>; <a href="#pq_traits">Traits</a>
- discusses ways to differentiate between the different traits of
- different implementations.</p>
-
- <h2><a name="pq_it" id="pq_it">Iterators</a></h2>
-
- <p>There are many different underlying-data structures for
- implementing priority queues. Unfortunately, most such
- structures are oriented towards making <tt>push</tt> and
- <tt>top</tt> efficient, and consequently don't allow efficient
- access of other elements: for instance, they cannot support an efficient
- <tt>find</tt> method. In the use case where it
- is important to both access and "do something with" an
- arbitrary value, one would be out of luck. For example, many graph algorithms require
- modifying a value (typically increasing it in the sense of the
- priority queue's comparison functor).</p>
-
- <p>In order to access and manipulate an arbitrary value in a
- priority queue, one needs to reference the internals of the
- priority queue from some form of an associative container -
- this is unavoidable. Of course, in order to maintain the
- encapsulation of the priority queue, this needs to be done in a
- way that minimizes exposure to implementation internals.</p>
-
- <p>In <tt>pb_ds</tt> the priority queue's <tt>insert</tt>
- method returns an iterator, which if valid can be used for subsequent <tt>modify</tt> and
- <tt>erase</tt> operations. This both preserves the priority
- queue's encapsulation, and allows accessing arbitrary values (since the
- returned iterators from the <tt>push</tt> operation can be
- stored in some form of associative container).</p>
-
- <p>Priority queues' iterators present a problem regarding their
- invalidation guarantees. One assumes that calling
- <tt><b>operator</b>++</tt> on an iterator will associate it
- with the "next" value. Priority-queues are
- self-organizing: each operation changes what the "next" value
- means. Consequently, it does not make sense that <tt>push</tt>
- will return an iterator that can be incremented - this can have
- no possible use. Also, as in the case of hash-based containers,
- it is awkward to define if a subsequent <tt>push</tt> operation
- invalidates a prior returned iterator: it invalidates it in the
- sense that its "next" value is not related to what it
- previously considered to be its "next" value. However, it might not
- invalidate it, in the sense that it can be
- de-referenced and used for <tt>modify</tt> and <tt>erase</tt>
- operations.</p>
-
- <p>Similarly to the case of the other unordered associative
- containers, <tt>pb_ds</tt> uses a distinction between
- point-type and range type iterators. A priority queue's <tt>iterator</tt> can always be
- converted to a <tt>point_iterator</tt>, and a
- <tt>const_iterator</tt> can always be converted to a
- <tt>const_point_iterator</tt>.</p>
-
- <p>The following snippet demonstrates manipulating an arbitrary
- value:</p>
- <pre>
-<i>// A priority queue of integers.</i>
-<a href=
-"priority_queue.html">priority_queue</a>&lt;<b>int</b>&gt; p;
-
-<i>// Insert some values into the priority queue.</i>
-<a href=
-"priority_queue.html">priority_queue</a>&lt;<b>int</b>&gt;::point_iterator it = p.push(0);
-
-p.push(1);
-p.push(2);
-
-<i>// Now modify a value.</i>
-p.modify(it, 3);
-
-assert(p.top() == 3);
-</pre>
-
- <p>(<a href="pq_examples.html#xref">Priority Queue
- Examples::Cross-Referencing</a> shows a more detailed
- example.)</p>
-
- <p>It should be noted that an alternative design could embed an
- associative container in a priority queue. Could, but most probably should not. To begin with, it should be noted that one
- could always encapsulate a priority queue and an associative
- container mapping values to priority queue iterators with no
- performance loss. One cannot, however, "un-encapsulate" a
- priority queue embedding an associative container, which might
- lead to performance loss. Assume, that one needs to
- associate each value with some data unrelated to priority
- queues. Then using <tt>pb_ds</tt>'s design, one could use an
- associative container mapping each value to a pair consisting
- of this data and a priority queue's iterator. Using the
- embedded method would need to use two associative
- containers. Similar problems might arise in cases where a value
- can reside simultaneously in many priority queues.</p>
-
- <h2><a name="pq_imp" id="pq_imp">Implementations</a></h2>
-
- <p>There are three main implementations of priority queues: the
- first employs a binary heap, typically one which uses a
- sequence; the second uses a tree (or forest of trees), which is
- typically less structured than an associative container's tree;
- the third simply uses an associative container. These are
- shown, respectively, in Figures <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a> A1 and A2, Figure <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a> B, and Figures <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a> C.</p>
-
- <h6 class="c1"><a name="pq_different_underlying_dss" id=
- "pq_different_underlying_dss"><img src=
- "pq_different_underlying_dss.png" alt="no image" /></a></h6>
-
- <h6 class="c1">Underlying Priority-Queue Data-Structures.</h6>
-
- <p>Roughly speaking, any value that is both pushed and popped
- from a priority queue must incur a logarithmic expense (in the
- amortized sense). Any priority queue implementation that would
- avoid this, would violate known bounds on comparison-based
- sorting (see, <i>e.g.</i>, [<a href=
- "references.html#clrs2001">clrs2001</a>] and <a href=
- "references.html#brodal96priority">brodal96priority</a>]).</p>
-
- <p>Most implementations do
- not differ in the asymptotic amortized complexity of
- <tt>push</tt> and <tt>pop</tt> operations, but they differ in
- the constants involved, in the complexity of other operations
- (<i>e.g.</i>, <tt>modify</tt>), and in the worst-case
- complexity of single operations. In general, the more
- "structured" an implementation (<i>i.e.</i>, the more internal
- invariants it possesses) - the higher its amortized complexity
- of <tt>push</tt> and <tt>pop</tt> operations.</p>
-
- <p><tt>pb_ds</tt> implements different algorithms using a
- single class: <a href="priority_queue.html">priority_queue</a>.
- Instantiating the <tt>Tag</tt> template parameter, "selects"
- the implementation:</p>
-
- <ol>
- <li>Instantiating <tt>Tag = <a href=
- "binary_heap_tag.html">binary_heap_tag</a></tt> creates
- a binary heap of the form in Figures <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a> A1 or A2. The former is internally
- selected by <a href="priority_queue.html">priority_queue</a>
- if <tt>Value_Type</tt> is instantiated by a primitive type
- (<i>e.g.</i>, an <tt><b>int</b></tt>); the latter is
- internally selected for all other types (<i>e.g.</i>,
- <tt>std::string</tt>). This implementations is relatively
- unstructured, and so has good <tt>push</tt> and <tt>pop</tt>
- performance; it is the "best-in-kind" for primitive
- types, <i>e.g.</i>, <tt><b>int</b></tt>s. Conversely, it has
- high worst-case performance, and can support only linear-time
- <tt>modify</tt> and <tt>erase</tt> operations; this is
- explained further in <a href="#pq_traits">Traits</a>.</li>
-
- <li>Instantiating <tt>Tag = <a href=
- "pairing_heap_tag.html">pairing_heap_tag</a></tt>
- creates a pairing heap of the form in Figure <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a> B. This implementations too is relatively
- unstructured, and so has good <tt>push</tt> and <tt>pop</tt>
- performance; it is the "best-in-kind" for non-primitive
- types, <i>e.g.</i>, <tt>std:string</tt>s. It also has very
- good worst-case <tt>push</tt> and <tt>join</tt> performance
- (<i>O(1)</i>), but has high worst-case <tt>pop</tt>
- complexity.</li>
-
- <li>Instantiating <tt>Tag = <a href=
- "binomial_heap_tag.html">binomial_heap_tag</a></tt>
- creates a binomial heap of the form in Figure <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a> B. This implementations is more
- structured than a pairing heap, and so has worse
- <tt>push</tt> and <tt>pop</tt> performance. Conversely, it
- has sub-linear worst-case bounds for <tt>pop</tt>,
- <i>e.g.</i>, and so it might be preferred in cases where
- responsiveness is important.</li>
-
- <li>Instantiating <tt>Tag = <a href=
- "rc_binomial_heap_tag.html">rc_binomial_heap_tag</a></tt>
- creates a binomial heap of the form in Figure <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a> B, accompanied by a redundant counter
- which governs the trees. This implementations is therefore
- more structured than a binomial heap, and so has worse
- <tt>push</tt> and <tt>pop</tt> performance. Conversely, it
- guarantees <i>O(1)</i> <tt>push</tt> complexity, and so it
- might be preferred in cases where the responsiveness of a
- binomial heap is insufficient.</li>
-
- <li>Instantiating <tt>Tag = <a href=
- "thin_heap_tag.html">thin_heap_tag</a></tt> creates a
- thin heap of the form in Figure <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a> B. This implementations too is more
- structured than a pairing heap, and so has worse
- <tt>push</tt> and <tt>pop</tt> performance. Conversely, it
- has better worst-case and identical amortized complexities
- than a Fibonacci heap, and so might be more appropriate for
- some graph algorithms.</li>
- </ol>
-
- <p><a href="pq_performance_tests.html">Priority-Queue
- Performance Tests</a> shows some results for the above, and
- discusses these points further.</p>
-
- <p>Of course, one can use any order-preserving associative
- container as a priority queue, as in Figure <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a> C, possibly by creating an adapter class
- over the associative container (much as
- <tt>std::priority_queue</tt> can adapt <tt>std::vector</tt>).
- This has the advantage that no cross-referencing is necessary
- at all; the priority queue itself is an associative container.
- Most associative containers are too structured to compete with
- priority queues in terms of <tt>push</tt> and <tt>pop</tt>
- performance.</p>
-
- <h2><a name="pq_traits" id="pq_traits">Traits</a></h2>
-
- <p>It would be nice if all priority queues could
- share exactly the same behavior regardless of implementation. Sadly, this is not possible. Just one for instance is in join operations: joining
- two binary heaps might throw an exception (not corrupt
- any of the heaps on which it operates), but joining two pairing
- heaps is exception free.</p>
-
- <p>Tags and traits are very useful for manipulating generic
- types. <a href=
- "priority_queue.html"><tt>__gnu_pbds::priority_queue</tt></a>
- publicly defines <tt>container_category</tt> as one of the tags
- discussed in <a href="#pq_imp">Implementations</a>. Given any
- container <tt>Cntnr</tt>, the tag of the underlying
- data structure can be found via <tt><b>typename</b>
- Cntnr::container_category</tt>; this is one of the types shown in
- Figure <a href="#pq_tag_cd">Data-structure tag class
- hierarchy</a>.</p>
-
- <h6 class="c1"><a name="pq_tag_cd" id=
- "pq_tag_cd"><img src="priority_queue_tag_cd.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Data-structure tag class hierarchy.</h6>
-
- <p>Additionally, a traits mechanism can be used to query a
- container type for its attributes. Given any container
- <tt>Cntnr</tt>, then <tt><a href=
- "assoc_container_traits.html">__gnu_pbds::container_traits</a>&lt;Cntnr&gt;</tt>
- is a traits class identifying the properties of the
- container.</p>
-
- <p>To find if a container might throw if two of its objects are
- joined, one can use <a href=
- "assoc_container_traits.html"><tt>container_traits</tt></a><tt>&lt;Cntnr&gt;::split_join_can_throw</tt>,
- for example.</p>
-
- <p>Different priority-queue implementations have different invalidation guarantees. This is
- especially important, since as explained in <a href=
- "#pq_it">Iterators</a>, there is no way to access an arbitrary
- value of priority queues except for iterators. Similarly to
- associative containers, one can use
- <a href=
- "assoc_container_traits.html"><tt>container_traits</tt></a><tt>&lt;Cntnr&gt;::invalidation_guarantee</tt>
- to get the invalidation guarantee type of a priority queue.</p>
-
- <p>It is easy to understand from Figure <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a>, what <a href=
- "assoc_container_traits.html"><tt>container_traits</tt></a><tt>&lt;Cntnr&gt;::invalidation_guarantee</tt>
- will be for different implementations. All implementations of
- type <a href="#pq_different_underlying_dss">Underlying
- Priority-Queue Data-Structures</a> B have <a href=
- "point_invalidation_guarantee.html"><tt>point_invalidation_guarantee</tt></a>:
- the container can freely internally reorganize the nodes -
- range-type iterators are invalidated, but point-type iterators
- are always valid. Implementations of type <a href=
- "#pq_different_underlying_dss">Underlying Priority-Queue
- Data-Structures</a> A1 and A2 have <a href=
- "basic_invalidation_guarantee.html"><tt>basic_invalidation_guarantee</tt></a>:
- the container can freely internally reallocate the array - both
- point-type and range-type iterators might be invalidated.</p>
-
- <p>This has major implications, and constitutes a good reason to avoid
- using binary heaps. A binary heap can perform <tt>modify</tt>
- or <tt>erase</tt> efficiently <u>given a valid point-type
- iterator</u>. However, inn order to supply it with a valid point-type
- iterator, one needs to iterate (linearly) over all
- values, then supply the relevant iterator (recall that a
- range-type iterator can always be converted to a point-type
- iterator). This means that if the number of <tt>modify</tt> or
- <tt>erase</tt> operations is non-negligible (say
- super-logarithmic in the total sequence of operations) - binary
- heaps will perform badly.</p>
- <pre>
-
-</pre>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_different_underlying_dss.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_different_underlying_dss.png
deleted file mode 100644
index 9d84791fc..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_different_underlying_dss.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_examples.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_examples.html
deleted file mode 100644
index 15311ebc3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_examples.html
+++ /dev/null
@@ -1,54 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Examples</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Priority-Queue Examples</h1>
-
- <h2><a name="basic_usage" id="basic_usage">Basic Use</a></h2>
-
- <ol>
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_priority_queue.cc"><tt>basic_priority_queue.cc</tt></a>
- Basic use of priority queues.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/priority_queue_split_join.cc"><tt>priority_queue_split_join.cc</tt></a>
- Splitting and joining priority queues.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/priority_queue_erase_if.cc"><tt>priority_queue_erase_if.cc</tt></a>
- Conditionally erasing values from a container object.</li>
- </ol>
-
- <h2><a name="generics" id="generics">Generics</a></h2>
-
- <ol>
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/priority_queue_container_traits.cc"><tt>priority_queue_container_traits.cc</tt></a>
- Using <a href="assoc_container_traits.html"><tt>container_traits</tt></a>
- to query about underlying data structure behavior.</li>
- </ol>
-
- <h2><a name="xref" id="xref">Cross Referencing</a></h2>
-
-
- <ol>
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/priority_queue_xref.cc"><tt>priority_queue_xref.cc</tt></a>
- Cross referencing an associative container and a priority
- queue.</li>
-
- <li><a href= "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/priority_queue_dijkstra.cc"><tt>priority_queue_dijkstra.cc</tt></a>
- Cross referencing a vector and a priority queue using a
- <u>very</u> simple version of Dijkstra's shortest path
- algorithm.</li>
- </ol>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_performance_tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_performance_tests.html
deleted file mode 100644
index 3a6b26912..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_performance_tests.html
+++ /dev/null
@@ -1,332 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Priority-Queue Performance Tests</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Priority-Queue Performance Tests</h1>
-<h2><a name="settings" id="settings">Settings</a></h2>
-<p>This section describes performance tests and their results.
- In the following, <a href="#gcc"><u>g++</u></a>, <a href="#msvc"><u>msvc++</u></a>, and <a href="#local"><u>local</u></a> (the build used for generating this
- documentation) stand for three different builds:</p>
-<div id="gcc_settings_div">
-<div class="c1">
-<h3><a name="gcc" id="gcc"><u>g++</u></a></h3>
-<ul>
-<li>CPU speed - cpu MHz : 2660.644</li>
-<li>Memory - MemTotal: 484412 kB</li>
-<li>Platform -
- Linux-2.6.12-9-386-i686-with-debian-testing-unstable</li>
-<li>Compiler - g++ (GCC) 4.0.2 20050808 (prerelease)
- (Ubuntu 4.0.1-4ubuntu9) Copyright (C) 2005 Free Software
- Foundation, Inc. This is free software; see the source
- for copying conditions. There is NO warranty; not even
- for MERCHANTABILITY or FITNESS FOR A PARTICULAR
- PURPOSE.</li>
-</ul>
-</div>
-<div class="c2"></div>
-</div>
-<div id="msvc_settings_div">
-<div class="c1">
-<h3><a name="msvc" id="msvc"><u>msvc++</u></a></h3>
-<ul>
-<li>CPU speed - cpu MHz : 2660.554</li>
-<li>Memory - MemTotal: 484412 kB</li>
-<li>Platform - Windows XP Pro</li>
-<li>Compiler - Microsoft (R) 32-bit C/C++ Optimizing
- Compiler Version 13.10.3077 for 80x86 Copyright (C)
- Microsoft Corporation 1984-2002. All rights
- reserved.</li>
-</ul>
-</div>
-<div class="c2"></div>
-</div>
-<div id="local_settings_div"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h3><a name = "local"><u>local</u></a></h3><ul>
-<li>CPU speed - cpu MHz : 2250.000</li>
-<li>Memory - MemTotal: 2076248 kB</li>
-<li>Platform - Linux-2.6.16-1.2133_FC5-i686-with-redhat-5-Bordeaux</li>
-<li>Compiler - g++ (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
-Copyright (C) 2006 Free Software Foundation, Inc.
-This is free software; see the source for copying conditions. There is NO
-warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-</li>
-</ul>
-</div><div style = "width: 100%; height: 20px"></div></div>
-<h2><a name="pq_tests" id="pq_tests">Tests</a></h2>
-<ol>
-<li><a href="priority_queue_text_push_timing_test.html">Priority Queue
- Text <tt>push</tt> Timing Test</a></li>
-<li><a href="priority_queue_text_push_pop_timing_test.html">Priority
- Queue Text <tt>push</tt> and <tt>pop</tt> Timing
- Test</a></li>
-<li><a href="priority_queue_random_int_push_timing_test.html">Priority
- Queue Random Integer <tt>push</tt> Timing Test</a></li>
-<li><a href="priority_queue_random_int_push_pop_timing_test.html">Priority
- Queue Random Integer <tt>push</tt> and <tt>pop</tt> Timing
- Test</a></li>
-<li><a href="priority_queue_text_pop_mem_usage_test.html">Priority Queue
- Text <tt>pop</tt> Memory Use Test</a></li>
-<li><a href="priority_queue_text_join_timing_test.html">Priority Queue
- Text <tt>join</tt> Timing Test</a></li>
-<li><a href="priority_queue_text_modify_up_timing_test.html">Priority
- Queue Text <tt>modify</tt> Timing Test - I</a></li>
-<li><a href="priority_queue_text_modify_down_timing_test.html">Priority
- Queue Text <tt>modify</tt> Timing Test - II</a></li>
-</ol>
-<h2><a name="pq_observations" id="pq_observations">Observations</a></h2>
-<h3><a name="pq_observations_cplx" id="pq_observations_cplx">Underlying Data Structures
- Complexity</a></h3>
-<p>The following table shows the complexities of the different
- underlying data structures in terms of orders of growth. It is
- interesting to note that this table implies something about the
- constants of the operations as well (see <a href="#pq_observations_amortized_push_pop">Amortized <tt>push</tt>
- and <tt>pop</tt> operations</a>).</p>
-<table class="c1" width="100%" border="1" summary="pq complexities">
-<tr>
-<td align="left"></td>
-<td align="left"><tt>push</tt></td>
-<td align="left"><tt>pop</tt></td>
-<td align="left"><tt>modify</tt></td>
-<td align="left"><tt>erase</tt></td>
-<td align="left"><tt>join</tt></td>
-</tr>
-<tr>
-<td align="left">
-<p><tt>std::priority_queue</tt></p>
-</td>
-<td align="left">
-<p><i>&Theta;(n)</i> worst</p>
-<p><i>&Theta;(log(n))</i> amortized</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(log(n)) Worst</p>
-</td>
-<td align="left">
-<p><i>Theta;(n log(n))</i> Worst</p>
-<p><sub><a href="#std_mod1">[std note 1]</a></sub></p>
-</td>
-<td align="left">
-<p class="c3">&Theta;(n log(n))</p>
-<p><sub><a href="#std_mod2">[std note 2]</a></sub></p>
-</td>
-<td align="left">
-<p class="c3">&Theta;(n log(n))</p>
-<p><sub><a href="#std_mod1">[std note 1]</a></sub></p>
-</td>
-</tr>
-<tr>
-<td align="left">
-<p><a href="priority_queue.html"><tt>priority_queue</tt></a></p>
-<p>with <tt>Tag</tt> =</p>
-<p><a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a></p>
-</td>
-<td align="left">
-<p class="c1">O(1)</p>
-</td>
-<td align="left">
-<p><i>&Theta;(n)</i> worst</p>
-<p><i>&Theta;(log(n))</i> amortized</p>
-</td>
-<td align="left">
-<p><i>&Theta;(n)</i> worst</p>
-<p><i>&Theta;(log(n))</i> amortized</p>
-</td>
-<td align="left">
-<p><i>&Theta;(n)</i> worst</p>
-<p><i>&Theta;(log(n))</i> amortized</p>
-</td>
-<td align="left">
-<p class="c1">O(1)</p>
-</td>
-</tr>
-<tr>
-<td align="left">
-<p><a href="priority_queue.html"><tt>priority_queue</tt></a></p>
-<p>with <tt>Tag</tt> =</p>
-<p><a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a></p>
-</td>
-<td align="left">
-<p><i>&Theta;(n)</i> worst</p>
-<p><i>&Theta;(log(n))</i> amortized</p>
-</td>
-<td align="left">
-<p><i>&Theta;(n)</i> worst</p>
-<p><i>&Theta;(log(n))</i> amortized</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(n)</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(n)</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(n)</p>
-</td>
-</tr>
-<tr>
-<td align="left">
-<p><a href="priority_queue.html"><tt>priority_queue</tt></a></p>
-<p>with <tt>Tag</tt> =</p>
-<p><a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a></p>
-</td>
-<td align="left">
-<p><i>&Theta;(log(n))</i> worst</p>
-<p><i>O(1)</i> amortized</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(log(n))</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(log(n))</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(log(n))</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(log(n))</p>
-</td>
-</tr>
-<tr>
-<td align="left">
-<p><a href="priority_queue.html"><tt>priority_queue</tt></a></p>
-<p>with <tt>Tag</tt> =</p>
-<p><a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a></p>
-</td>
-<td align="left">
-<p class="c1">O(1)</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(log(n))</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(log(n))</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(log(n))</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(log(n))</p>
-</td>
-</tr>
-<tr>
-<td align="left">
-<p><a href="priority_queue.html"><tt>priority_queue</tt></a></p>
-<p>with <tt>Tag</tt> =</p>
-<p><a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a></p>
-</td>
-<td align="left">
-<p class="c1">O(1)</p>
-</td>
-<td align="left">
-<p><i>&Theta;(n)</i> worst</p>
-<p><i>&Theta;(log(n))</i> amortized</p>
-</td>
-<td align="left">
-<p><i>&Theta;(log(n))</i> worst</p>
-<p><i>O(1)</i> amortized,</p>or
-
- <p><i>&Theta;(log(n))</i> amortized</p>
-<p><sub><a href="#thin_heap_note">[thin_heap_note]</a></sub></p>
-</td>
-<td align="left">
-<p><i>&Theta;(n)</i> worst</p>
-<p><i>&Theta;(log(n))</i> amortized</p>
-</td>
-<td align="left">
-<p class="c1">&Theta;(n)</p>
-</td>
-</tr>
-</table>
-<p><sub><a name="std_mod1" id="std_mod1">[std note 1]</a> This
- is not a property of the algorithm, but rather due to the fact
- that the STL's priority queue implementation does not support
- iterators (and consequently the ability to access a specific
- value inside it). If the priority queue is adapting an
- <tt>std::vector</tt>, then it is still possible to reduce this
- to <i>&Theta;(n)</i> by adapting over the STL's adapter and
- using the fact that <tt>top</tt> returns a reference to the
- first value; if, however, it is adapting an
- <tt>std::deque</tt>, then this is impossible.</sub></p>
-<p><sub><a name="std_mod2" id="std_mod2">[std note 2]</a> As
- with <a href="#std_mod1">[std note 1]</a>, this is not a
- property of the algorithm, but rather the STL's implementation.
- Again, if the priority queue is adapting an
- <tt>std::vector</tt> then it is possible to reduce this to
- <i>&Theta;(n)</i>, but with a very high constant (one must call
- <tt>std::make_heap</tt> which is an expensive linear
- operation); if the priority queue is adapting an
- <tt>std::dequeu</tt>, then this is impossible.</sub></p>
-<p><sub><a name="thin_heap_note" id="thin_heap_note">[thin_heap_note]</a> A thin heap has
- <i>&amp;Theta(log(n))</i> worst case <tt>modify</tt> time
- always, but the amortized time depends on the nature of the
- operation: I) if the operation increases the key (in the sense
- of the priority queue's comparison functor), then the amortized
- time is <i>O(1)</i>, but if II) it decreases it, then the
- amortized time is the same as the worst case time. Note that
- for most algorithms, I) is important and II) is not.</sub></p>
-<h3><a name="pq_observations_amortized_push_pop" id="pq_observations_amortized_push_pop">Amortized <tt>push</tt>
- and <tt>pop</tt> operations</a></h3>
-<p>In many cases, a priority queue is needed primarily for
- sequences of <tt>push</tt> and <tt>pop</tt> operations. All of
- the underlying data structures have the same amortized
- logarithmic complexity, but they differ in terms of
- constants.</p>
-<p>The table above shows that the different data structures are
- "constrained" in some respects. In general, if a data structure
- has lower worst-case complexity than another, then it will
- perform slower in the amortized sense. Thus, for example a
- redundant-counter binomial heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> with
- <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>)
- has lower worst-case <tt>push</tt> performance than a binomial
- heap (<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>),
- and so its amortized <tt>push</tt> performance is slower in
- terms of constants.</p>
-<p>As the table shows, the "least constrained" underlying
- data structures are binary heaps and pairing heaps.
- Consequently, it is not surprising that they perform best in
- terms of amortized constants.</p>
-<ol>
-<li>Pairing heaps seem to perform best for non-primitive
- types (<i>e.g.</i>, <tt>std::string</tt>s), as shown by
- <a href="priority_queue_text_push_timing_test.html">Priority
- Queue Text <tt>push</tt> Timing Test</a> and <a href="priority_queue_text_push_pop_timing_test.html">Priority
- Queue Text <tt>push</tt> and <tt>pop</tt> Timing
- Test</a></li>
-<li>binary heaps seem to perform best for primitive types
- (<i>e.g.</i>, <tt><b>int</b></tt>s), as shown by <a href="priority_queue_random_int_push_timing_test.html">Priority
- Queue Random Integer <tt>push</tt> Timing Test</a> and
- <a href="priority_queue_random_int_push_pop_timing_test.html">Priority
- Queue Random Integer <tt>push</tt> and <tt>pop</tt> Timing
- Test</a>.</li>
-</ol>
-<h3><a name="pq_observations_graph" id="pq_observations_graph">Graph Algorithms</a></h3>
-<p>In some graph algorithms, a decrease-key operation is
- required [<a href="references.html#clrs2001">clrs2001</a>];
- this operation is identical to <tt>modify</tt> if a value is
- increased (in the sense of the priority queue's comparison
- functor). The table above and <a href="priority_queue_text_modify_up_timing_test.html">Priority Queue
- Text <tt>modify</tt> Timing Test - I</a> show that a thin heap
- (<a href="priority_queue.html"><tt>priority_queue</tt></a> with
- <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>)
- outperforms a pairing heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> with
- <tt>Tag</tt> =<tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>),
- but the rest of the tests show otherwise.</p>
-<p>This makes it difficult to decide which implementation to
- use in this case. Dijkstra's shortest-path algorithm, for
- example, requires <i>&Theta;(n)</i> <tt>push</tt> and
- <tt>pop</tt> operations (in the number of vertices), but
- <i>O(n<sup>2</sup>)</i> <tt>modify</tt> operations, which can
- be in practice <i>&Theta;(n)</i> as well. It is difficult to
- find an <i>a-priori</i> characterization of graphs in which the
- <u>actual</u> number of <tt>modify</tt> operations will dwarf
- the number of <tt>push</tt> and <tt>pop</tt> operations.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_regression_tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_regression_tests.html
deleted file mode 100644
index 9084409d3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_regression_tests.html
+++ /dev/null
@@ -1,52 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Priority-Queue Regression Tests</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Priority-Queue Regression Tests</h1>
-
- <h2><a name="assoc_desc" id="assoc_desc">Description</a></h2>
-
- <p>The library contains a single comprehensive regression test.
- For a given container type in <tt>pb_ds</tt>, the test creates
- an object of the container type and an object of the
- corresponding STL type (<i>i.e.</i>,
- <tt>std::priority_queue</tt>). It then performs a random
- sequence of methods with random arguments (<i>e.g.</i>, pushes,
- pops, and so forth) on both objects. At each operation, the
- test checks the return value of the method, and optionally both
- compares <tt>pb_ds</tt>'s object with the STL's object as well
- as performing other consistency checks on <tt>pb_ds</tt>'s
- object (<i>e.g.</i>, that the size returned by the
- <tt>size</tt> method corresponds to the distance between its
- <tt>begin</tt> and end iterators).</p>
-
- <p>Additionally, the test integrally checks exception safety
- and resource leaks. This is done as follows. A special
- allocator type, written for the purpose of the test, both
- randomly throws an exceptions when allocations are performed,
- and tracks allocations and de-allocations. The exceptions thrown
- at allocations simulate memory-allocation failures; the
- tracking mechanism checks for memory-related bugs (<i>e.g.</i>,
- resource leaks and multiple de-allocations). Both
- <tt>pb_ds</tt>'s containers and the containers' value-types are
- configured to use this allocator.</p>
-
- <h2><a name="pq_tests" id="pq_tests">Tests</a></h2>
-
- <p><a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/regression/priority_queue_rand.cc"><tt>priority_queue_rand.cc</tt></a>
- checks all priority queue types.</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_tests.html
deleted file mode 100644
index de8cb447c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/pq_tests.html
+++ /dev/null
@@ -1,24 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Priority-Queue Tests</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Priority-Queue Tests</h1>
-
- <p><a href="pq_regression_tests.html">Priority-Queue Regression
- Tests</a> describes the regression tests; <a href=
- "pq_performance_tests.html">Priority-Queue Performance
- Tests</a> describes the performance tests.</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/prerequisites.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/prerequisites.html
deleted file mode 100644
index 7c8888499..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/prerequisites.html
+++ /dev/null
@@ -1,46 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Prerequisites</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Usage Prerequisites</h1>
-
- <p><tt>pb_ds</tt> has been successfully tested with the
- following compilers:</p>
-
- <ol>
- <li>g++ 3.3.1, 3.4.4, 4.0, 4.1, and what will be 4.2</li>
-
- <li>Intel icpc 8.1 and 9</li>
-
- <li>Visual C++ .Net 2005</li>
- </ol>
-
- <p>The library contains only header files, and does not require
- any other libraries except the STL. All classes are defined in
- <tt><b>namespace</b> pb_ds</tt>. The library internally uses
- macros beginning with <tt>PB_DS</tt> (<i>e.g.</i>, for header
- guards), but <tt>#<b>undef</b></tt>s anything it
- <tt>#<b>define</b></tt>s (except for header guards). Compiling
- the library in an environment where macros beginning in
- <tt>PB_DS</tt> are defined, may yield unpredictable results in
- compilation, execution, or both.</p>
-
- <p> Further dependencies are necessary to create the visual output
- for the performance tests. To create these graphs, two additional
- packages will be needed: <b>pychart</b> and <b>Beautiful
- Soup</b>. Both are freely available.
- </p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue.html
deleted file mode 100644
index def310f0c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue.html
+++ /dev/null
@@ -1,995 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>priority_queue Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>priority_queue</tt> Interface</h1>
-
- <p>Basic priority queue.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/priority_queue.hpp"><tt>priority_queue.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Value_Type216514186" id=
-"Value_Type216514186"><b>typename</b> Value_Type</a>
-</pre>
- </td>
-
- <td>
- <p>Value type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Cmp_Fn294335" id="Cmp_Fn294335"><b>class</b> Cmp_Fn </a>
-</pre>
- </td>
-
- <td>
- <p>Comparison functor.</p>
- </td>
-
- <td>
- <pre>
-std::less&lt;<a href=
-"#Value_Type216514186"><tt>Value_Type</tt></a>&gt;
-</pre>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Tag278938" id="Tag278938"><b>class</b> Tag </a>
-</pre>
- </td>
-
- <td>
- <p>Data-structure tag.</p>
- </td>
-
- <td><a href="pairing_heap_tag.html"><span class=
- "c2"><tt>pairing_heap_tag</tt></span></a></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator </a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>
- <pre>
-std::allocator&lt;<b>char</b>&gt;
-</pre>
- </td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">General Container
- Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#Allocator35940069"><tt>Allocator</tt></a>::size_type
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="difference_type868028452" id=
-"difference_type868028452">difference_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#Allocator35940069"><tt>Allocator</tt></a>::difference_type
-</pre>
- </td>
-
- <td>
- <p>Difference type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">Categories</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="container_category1247973216" id=
-"container_category1247973216">container_category</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Tag278938"><tt>Tag</tt></a>
-</pre>
- </td>
-
- <td>
- <p>The underlying mapped-structure tag of the
- container.</p>
-
- <p>This is one of:</p>
-
- <ol>
- <li><a href="binary_heap_tag.html"><span class=
- "c2"><tt>binary_heap_tag</tt></span></a></li>
-
- <li><a href="binomial_heap_tag.html"><span class=
- "c2"><tt>binomial_heap_tag</tt></span></a></li>
-
- <li><a href="rc_binomial_heap_tag.html"><span class=
- "c2"><tt>rc_binomial_heap_tag</tt></span></a></li>
-
- <li><a href="pairing_heap_tag.html"><span class=
- "c2"><tt>pairing_heap_tag</tt></span></a></li>
-
- <li><a href="thin_heap_tag.html"><span class=
- "c2"><tt>thin_heap_tag</tt></span></a></li>
- </ol>
- </td>
- </tr>
- </table>
-
- <h3><a name="link5" id="link5">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="cmp_fn394495" id="cmp_fn394495">cmp_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Cmp_Fn294335"><tt>Cmp_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Comparison functor type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="allocator48440069" id="allocator48440069">allocator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Allocator35940069"><tt>Allocator</tt></a>
-</pre>
- </td>
-
- <td>
- <p><a href="#Allocator35940069"><tt>Allocator</tt></a>
- type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link6" id="link6">Value-Type Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="value_type279018186" id=
-"value_type279018186">value_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Value_Type216514186"><tt>Value_Type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Value type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="reference54418471" id="reference54418471">reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#value_type279018186"><tt>value_type</tt></a>&gt;::other::reference
-</pre>
- </td>
-
- <td>
- <p>Value reference type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_reference495461441" id=
-"const_reference495461441">const_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#value_type279018186"><tt>value_type</tt></a>&gt;::other::const_reference
-</pre>
- </td>
-
- <td>
- <p>Const value <a href=
- "#reference54418471"><tt>reference</tt></a> type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="pointer2179769" id="pointer2179769">pointer</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#value_type279018186"><tt>value_type</tt></a>&gt;::other::pointer
-</pre>
- </td>
-
- <td>
- <p>Value pointer type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_pointer878814947" id=
-"const_pointer878814947">const_pointer</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#value_type279018186"><tt>value_type</tt></a>&gt;::other::const_pointer
-</pre>
- </td>
-
- <td>
- <p>Const Value <a href=
- "#pointer2179769"><tt>pointer</tt></a> type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Iterator Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_point_iterator2364676009" id=
-"const_point_iterator2364676009">const_point_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Const point-type iterator.
-</pre>
- </td>
-
- <td>
- <p>Const point-type iterator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="point_iterator2789896775" id=
-"point_iterator2789896775">point_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Point-type iterator.
-</pre>
- </td>
-
- <td>
- <p>Point-type iterator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_iterator98626788" id=
-"const_iterator98626788">const_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Const range-type iterator.
-</pre>
- </td>
-
- <td>
- <p>Const range-type iterator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="iterator10418194" id="iterator10418194">iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Range-type iterator.
-</pre>
- </td>
-
- <td>
- <p>Range-type iterator.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link8" id="link8">Public Methods</a></h2>
-
- <h3><a name="link9" id="link9">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- priority_queue
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- priority_queue
- (<b>const</b> <a href=
-"#cmp_fn394495"><tt>cmp_fn</tt></a> &amp;r_cmp_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking some policy objects. <span class=
- "c1"><tt>r_cmp_fn</tt></span> will be copied by the
- <a href="#Cmp_Fn294335"><tt>Cmp_Fn</tt></a> object of the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- priority_queue
- (It first_it,
- It last_it)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of <a href=
- "#value_type279018186"><tt>value_type</tt></a>s. The
- <a href="#value_type279018186"><tt>value_type</tt></a>s
- between <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- priority_queue
- (It first_it,
- It last_it,
- <b>const</b> <a href=
-"#cmp_fn394495"><tt>cmp_fn</tt></a> &amp;r_cmp_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of <a href=
- "#value_type279018186"><tt>value_type</tt></a>s and some
- policy objects The <a href=
- "#value_type279018186"><tt>value_type</tt></a>s between
- <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object. <span class=
- "c1"><tt>r_cmp_fn</tt></span> will be copied by the
- <a href="#cmp_fn394495"><tt>cmp_fn</tt></a> object of the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- priority_queue
- (<b>const</b> <span class=
-"c2"><tt>priority_queue</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b>
- ~priority_queue
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<span class="c2"><tt>priority_queue</tt></span> &amp;
- <b>operator</b>=
- (<b>const</b> <span class=
-"c2"><tt>priority_queue</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Assignment operator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class="c2"><tt>priority_queue</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link10" id="link10">Information Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- size
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the number of distinct <a href=
- "#value_type279018186"><tt>value_type</tt></a> objects
- the container object is storing.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- max_size
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns an upper bound on the number of distinct
- <a href="#value_type279018186"><tt>value_type</tt></a>
- objects this container can store.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- empty
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns whether the container object is not storing
- any <a href=
- "#value_type279018186"><tt>value_type</tt></a>
- objects.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link11" id="link11">Insert Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href=
-"#point_iterator2789896775"><tt>point_iterator</tt></a>
- push
- (<a href=
-"#const_reference495461441"><tt>const_reference</tt></a> r_val)
-</pre>
- </td>
-
- <td>
- <p>Inserts a <a href=
- "#value_type279018186"><tt>value_type</tt></a> object.
- returns a <a href=
- "#point_iterator2789896775"><tt>point_iterator</tt></a>
- object associated with the new pushed <span class=
- "c1"><tt>r_val</tt></span>.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link12" id="link12">Find Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href=
-"#const_reference495461441"><tt>const_reference</tt></a>
- top
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#const_reference495461441"><tt>const_reference</tt></a>
- of the largest <a href=
- "#value_type279018186"><tt>value_type</tt></a> in the
- container object, i.e., a <a href=
- "#value_type279018186"><tt>value_type</tt></a> v_max for
- which any other <a href=
- "#value_type279018186"><tt>value_type</tt></a> v in the
- container object will satisfy !<a href=
- "#cmp_fn394495"><tt>cmp_fn</tt></a>()(v_max, v).</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link13" id="link13">Modify Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- modify
- (<a href=
-"#point_iterator2789896775"><tt>point_iterator</tt></a> it,
- <a href=
-"#const_reference495461441"><tt>const_reference</tt></a> r_new_val)
-</pre>
- </td>
-
- <td>
- <p>Modifies the <a href=
- "#value_type279018186"><tt>value_type</tt></a> associated
- with the <a href=
- "#point_iterator2789896775"><tt>point_iterator</tt></a>
- <span class="c1"><tt>it</tt></span> into <span class=
- "c1"><tt>r_new_val</tt></span>.</p>
-
- <p>To use this method, <a href=
- "#value_type279018186"><tt>value_type</tt></a> must be
- assignable.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link14" id="link14">Erase Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- pop
- ()
-</pre>
- </td>
-
- <td>
- <p>Pops the largest <a href=
- "#value_type279018186"><tt>value_type</tt></a>.</p>
-
- <p>If the container object is empty, results are
- undefined.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- erase
- (<a href=
-"#point_iterator2789896775"><tt>point_iterator</tt></a> it)
-</pre>
- </td>
-
- <td>
- <p>Erases the <a href=
- "#value_type279018186"><tt>value_type</tt></a> associated
- with the <a href=
- "#point_iterator2789896775"><tt>point_iterator</tt></a>
- <span class="c1"><tt>it</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> Pred&gt;
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- erase_if
- (Pred prd)
-</pre>
- </td>
-
- <td>
- <p>Erases any <a href=
- "#value_type279018186"><tt>value_type</tt></a> satisfying
- the predicate <span class="c1"><tt>prd</tt></span>;
- returns the number of <a href=
- "#value_type279018186"><tt>value_type</tt></a>s
- erased.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- clear
- ()
-</pre>
- </td>
-
- <td>
- <p>Clears the container object.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link15" id="link15">Split and join
- Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- join
- (<span class="c2"><tt>priority_queue</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Joins two container objects. When this function
- returns, <span class="c1"><tt>other</tt></span> will be
- empty.</p>
-
- <p>When calling this method, <span class=
- "c1"><tt>other</tt></span>'s policies must be
- equivalent to this object's policies.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> Pred&gt;
-<b>inline</b> <b>void</b>
- split
- (Pred prd,
- <span class="c2"><tt>priority_queue</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Splits into two container objects. When this function
- returns, <span class="c1"><tt>other</tt></span> will be
- contain only values v for which <span class=
- "c1"><tt>prd</tt></span>(v) is <tt><b>true</b></tt>.</p>
-
- <p>When calling this method, <span class=
- "c1"><tt>other</tt></span>'s policies must be
- equivalent to this object's policies.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link16" id="link16">Iteration Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#iterator10418194"><tt>iterator</tt></a>
- begin
- ()
-</pre>
- </td>
-
- <td>
- <p>Returns an <a href=
- "#iterator10418194"><tt>iterator</tt></a> corresponding
- to the first <a href=
- "#value_type279018186"><tt>value_type</tt></a> in the
- container.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href=
-"#const_iterator98626788"><tt>const_iterator</tt></a>
- begin
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a>
- corresponding to the first <a href=
- "#value_type279018186"><tt>value_type</tt></a> in the
- container.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#iterator10418194"><tt>iterator</tt></a>
- end
- ()
-</pre>
- </td>
-
- <td>
- <p>Returns an <a href=
- "#iterator10418194"><tt>iterator</tt></a> corresponding
- to the just-after-last <a href=
- "#value_type279018186"><tt>value_type</tt></a> in the
- container.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href=
-"#const_iterator98626788"><tt>const_iterator</tt></a>
- end
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a>
- corresponding to the just-after-last <a href=
- "#value_type279018186"><tt>value_type</tt></a> in the
- container.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test.html
deleted file mode 100644
index 903331d9d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test.html
+++ /dev/null
@@ -1,161 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Priority Queue Random Int Push Pop Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Priority Queue Random Integer <tt>push</tt> and
- <tt>pop</tt> Timing Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with i.i.d. integer
- keys into a container using <tt>push</tt> , then removes them
- using <tt>pop</tt> . It measures the average time for
- <tt>push</tt> and <tt>pop</tt> as a function of the number of
- values.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_random_int_push_pop_timing.cc">
-<tt>priority_queue_random_int_push_pop_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- data structures (see <a href="pq_design.html#pq_imp">Design::Priority
- Queues::Implementations</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and
- <a href="#NPL">NPL</a> shows the results for the native
- priority queues and <tt>pb_ds</tt> 's priority queues in
- <a href="pq_performance_tests.html#gcc"><u>g++</u></a>,
- <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="pq_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NPG_res_div">
-<div id="NPG_gcc">
-<div id="NPG_priority_queue_random_int_push_pop_timing_test">
-<div id="NPG_pq">
-<div id="NPG_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt___tt_pop_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_random_int_push_pop_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native and <tt>pb ds</tt> priority queue <tt>push</tt> <tt>pop</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPM_res_div">
-<div id="NPM_msvc">
-<div id="NPM_priority_queue_random_int_push_pop_timing_test">
-<div id="NPM_pq">
-<div id="NPM_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt___tt_pop_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_random_int_push_pop_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native and <tt>pb ds</tt> priority queue <tt>push</tt> <tt>pop</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPL_res_div">
-<div id="NPL_local">
-<div id="NPL_priority_queue_random_int_push_pop_timing_test">
-<div id="NPL_pq">
-<div id="NPL_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt___tt_pop_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_random_int_push_pop_timing_test_local.png" alt="no image" /></a></h6>NPL: Native and <tt>pb ds</tt> priority queue <tt>push</tt> <tt>pop</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>Binary heaps are the most suited for sequences of
- <tt>push</tt> and <tt>pop</tt> operations of primitive types
- (<i>e.g.</i> <tt><b>int</b></tt>s). This is explained in
- <a href="priority_queue_random_int_push_timing_test.html">Priority
- Queue Random Int <tt>push</tt> Timing Test</a> . (See <a href="priority_queue_text_push_pop_timing_test.html">Priority Queue
- Text <tt>push</tt> Timing Test</a> for the case of primitive
- types.)</p>
-<p>At first glance it seems that the STL's vector-based
- priority queue is approximately on par with <tt>pb_ds</tt>'s
- corresponding priority queue. There are two differences
- however:</p>
-<ol>
-<li>The STL's priority queue does not downsize the underlying
- vector (or deque) as the priority queue becomes smaller
- (see <a href="priority_queue_text_pop_mem_usage_test.html">Priority Queue
- Text <tt>pop</tt> Memory Use Test</a>). It is therefore
- gaining some speed at the expense of space.</li>
-<li>From <a href="priority_queue_random_int_push_pop_timing_test.html">Priority
- Queue Random Integer <tt>push</tt> and <tt>pop</tt> Timing
- Test</a>, it seems that the STL's priority queue is slower in
- terms of <tt>pus</tt> operations. Since the number of
- <tt>pop</tt> operations is at most that of <tt>push</tt>
- operations, the test here is the "best" for the STL's
- priority queue.</li>
-</ol>
-<p><a href="pq_performance_tests.html#pq_observations">Priority-Queue
- Performance Tests::Observations</a> discusses this further and
- summarizes.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_gcc.png
deleted file mode 100644
index 68f5e2b6b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_local.png
deleted file mode 100644
index 51f8211f1..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_msvc.png
deleted file mode 100644
index 4fc191c8b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_pop_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test.html
deleted file mode 100644
index ba91f601a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test.html
+++ /dev/null
@@ -1,200 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Priority Queue Random Int Push Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Priority Queue Random Integer <tt>push</tt> Timing
- Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with i.i.d integer keys
- into a container using <tt>push</tt> . It measures the average
- time for <tt>push</tt> as a function of the number of
- values.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_random_int_push_timing.cc"><tt>
- priority_queue_random_intpush_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- data structures (see <a href="pq_design.html#pq_imp">Design::Priority
- Queues::Implementations</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and
- <a href="#NPL">NPL</a> show the results for the native priority
- queues and <tt>pb_ds</tt> 's priority queues in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NBPG">NBPG</a>, <a href="#NBPM">NBPM</a>, and <a href="#NBPL">NBPL</a> shows the
- results for the binary-heap based native priority queues and
- <tt>pb_ds</tt> 's priority queues in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively</p>
-<div id="NPG_res_div">
-<div id="NPG_gcc">
-<div id="NPG_priority_queue_random_int_push_timing_test">
-<div id="NPG_pq">
-<div id="NPG_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_random_int_push_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPM_res_div">
-<div id="NPM_msvc">
-<div id="NPM_priority_queue_random_int_push_timing_test">
-<div id="NPM_pq">
-<div id="NPM_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_random_int_push_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPL_res_div">
-<div id="NPL_local">
-<div id="NPL_priority_queue_random_int_push_timing_test">
-<div id="NPL_pq">
-<div id="NPL_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_random_int_push_timing_test_local.png" alt="no image" /></a></h6>NPL: Native and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NBPG_res_div">
-<div id="NBPG_gcc">
-<div id="NBPG_binary_priority_queue_random_int_push_timing_test">
-<div id="NBPG_pq">
-<div id="NBPG_Native_and__tt_pb_ds_455tt__binary_priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBPG" id="NBPG"><img src="binary_priority_queue_random_int_push_timing_test_gcc.png" alt="no image" /></a></h6>NBPG: Native and <tt>pb ds</tt> binary priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NBPM_res_div">
-<div id="NBPM_msvc">
-<div id="NBPM_binary_priority_queue_random_int_push_timing_test">
-<div id="NBPM_pq">
-<div id="NBPM_Native_and__tt_pb_ds_455tt__binary_priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBPM" id="NBPM"><img src="binary_priority_queue_random_int_push_timing_test_msvc.png" alt="no image" /></a></h6>NBPM: Native and <tt>pb ds</tt> binary priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NBPL_res_div">
-<div id="NBPL_local">
-<div id="NBPL_binary_priority_queue_random_int_push_timing_test">
-<div id="NBPL_pq">
-<div id="NBPL_Native_and__tt_pb_ds_455tt__binary_priority_queue__tt_push_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBPL" id= "NBPL"><img src="binary_priority_queue_random_int_push_timing_test_local.png" alt="no image" /></a></h6>NBPL: Native and <tt>pb ds</tt> binary priority queue <tt>push</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>Binary heaps are the most suited for sequences of
- <tt>push</tt> and <tt>pop</tt> operations of primitive types
- (<i>e.g.</i> <tt><b>int</b></tt>s). They are less constrained
- than any other type, and since it is very efficient to store
- such types in arrays, they outperform even pairing heaps. (See
- <a href="priority_queue_text_push_timing_test.html">Priority
- Queue Text <tt>push</tt> Timing Test</a> for the case of
- non-primitive types.)</p>
-<p><a href="pq_performance_tests.html#pq_observations">Priority-Queue
- Performance Tests::Observations</a> discusses this further and
- summarizes.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_gcc.png
deleted file mode 100644
index ee8c9b7d9..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_local.png
deleted file mode 100644
index dead185fa..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_msvc.png
deleted file mode 100644
index 0a1a8eaef..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_random_int_push_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag.html
deleted file mode 100644
index 8b6d81c37..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>priority_queue_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>priority_queue_tag</tt> Interface</h1>
-
- <p>Basic priority-queue data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="container_tag.html"><span class=
-"c2"><tt>container_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.png
deleted file mode 100644
index ed8d875f0..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.svg b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.svg
deleted file mode 100644
index be007aecb..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_tag_cd.svg
+++ /dev/null
@@ -1,368 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Created with Inkscape (http://www.inkscape.org/) -->
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://web.resource.org/cc/"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:xlink="http://www.w3.org/1999/xlink"
- xmlns:sodipodi="http://inkscape.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- width="11in"
- height="8.5in"
- id="svg2"
- sodipodi:version="0.32"
- inkscape:version="0.43"
- version="1.0"
- sodipodi:docbase="/mnt/share/src/policy_based_data_structures/pb_ds_images"
- sodipodi:docname="pq_tag_diagram_2.svg"
- inkscape:export-filename="/mnt/share/src/policy_based_data_structures/pb_ds_images/pq_tag_diagram_2.png"
- inkscape:export-xdpi="90"
- inkscape:export-ydpi="90">
- <defs
- id="defs4">
- <marker
- inkscape:stockid="Arrow1Mstart"
- orient="auto"
- refY="0.0"
- refX="0.0"
- id="Arrow1Mstart"
- style="overflow:visible">
- <path
- id="path3311"
- d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
- style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none"
- transform="scale(0.4)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Sstart"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Sstart"
- style="overflow:visible">
- <path
- id="path3319"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(0.3,0,0,0.3,-1.5,0)" />
- </marker>
- <marker
- inkscape:stockid="Arrow1Sstart"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow1Sstart"
- style="overflow:visible">
- <path
- id="path3337"
- d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
- style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
- transform="scale(0.2,0.2)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Send"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Send"
- style="overflow:visible">
- <path
- id="path3316"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(-0.3,0,0,-0.3,1.5,0)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Mend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Mend"
- style="overflow:visible">
- <path
- id="path3322"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(-0.6,0,0,-0.6,3,0)" />
- </marker>
- <marker
- inkscape:stockid="Arrow1Lend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow1Lend"
- style="overflow:visible">
- <path
- id="path3346"
- d="M 0,0 L 5,-5 L -12.5,0 L 5,5 L 0,0 z "
- style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
- transform="scale(-0.8,-0.8)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Lstart"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Lstart"
- style="overflow:visible">
- <path
- id="path3331"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(1.1,0,0,1.1,-5.5,0)" />
- </marker>
- <marker
- inkscape:stockid="Arrow2Lend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Lend"
- style="overflow:visible">
- <path
- id="path3328"
- style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
- d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.97309,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
- transform="matrix(-1.1,0,0,-1.1,5.5,0)" />
- </marker>
- </defs>
- <sodipodi:namedview
- id="base"
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1.0"
- inkscape:pageopacity="0.0"
- inkscape:pageshadow="2"
- inkscape:zoom="2"
- inkscape:cx="608.69002"
- inkscape:cy="490.05621"
- inkscape:document-units="in"
- inkscape:current-layer="layer1"
- showguides="true"
- inkscape:guide-bbox="true"
- inkscape:window-width="1278"
- inkscape:window-height="973"
- inkscape:window-x="0"
- inkscape:window-y="0"
- gridtolerance="0.125in"
- guidetolerance="0.125in">
- <sodipodi:guide
- orientation="horizontal"
- position="629"
- id="guide1307" />
- <sodipodi:guide
- orientation="horizontal"
- position="449"
- id="guide1309" />
- <sodipodi:guide
- orientation="horizontal"
- position="269"
- id="guide1311" />
- <sodipodi:guide
- orientation="vertical"
- position="496"
- id="guide1313" />
- <sodipodi:guide
- orientation="vertical"
- position="383"
- id="guide1315" />
- <sodipodi:guide
- orientation="vertical"
- position="241"
- id="guide1317" />
- <sodipodi:guide
- orientation="vertical"
- position="680"
- id="guide1319" />
- <sodipodi:guide
- orientation="vertical"
- position="749"
- id="guide1321" />
- <sodipodi:guide
- orientation="vertical"
- position="124"
- id="guide1345" />
- <sodipodi:guide
- orientation="vertical"
- position="901"
- id="guide1347" />
- <sodipodi:guide
- orientation="horizontal"
- position="539"
- id="guide3390" />
- <sodipodi:guide
- orientation="horizontal"
- position="359"
- id="guide3392" />
- <sodipodi:guide
- orientation="vertical"
- position="280.5"
- id="guide3324" />
- <sodipodi:guide
- orientation="vertical"
- position="195"
- id="guide3326" />
- <sodipodi:guide
- orientation="vertical"
- position="427"
- id="guide3328" />
- <sodipodi:guide
- orientation="vertical"
- position="795"
- id="guide3340" />
- <sodipodi:guide
- orientation="horizontal"
- position="179"
- id="guide1395" />
- </sodipodi:namedview>
- <metadata
- id="metadata7">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- <dc:creator>
- <cc:Agent>
- <dc:title>Benjamin Kosnik</dc:title>
- </cc:Agent>
- </dc:creator>
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <g
- inkscape:label="Layer 1"
- inkscape:groupmode="layer"
- id="layer1">
- <rect
- y="382.17499"
- x="241.73018"
- height="23.200001"
- width="141.64481"
- id="rect3420"
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect3418"
- width="141.64481"
- height="23.200001"
- x="52.730194"
- y="382.17499" />
- <text
- xml:space="preserve"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="122.35258"
- y="395.91092"
- id="text3394"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1383"
- x="122.35258"
- y="395.91092">pairing_heap_tag</tspan></text>
- <text
- sodipodi:linespacing="100%"
- id="text3400"
- y="395.91092"
- x="310.55255"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
- xml:space="preserve"><tspan
- sodipodi:role="line"
- id="tspan1381"
- x="310.55255"
- y="395.91092">bionomial_heap_tag</tspan></text>
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect3380"
- width="141.64481"
- height="23.200001"
- x="425.57764"
- y="292.56177" />
- <text
- xml:space="preserve"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.5625;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="495.20001"
- y="307.09772"
- id="text1323"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1363"
- x="495.20001"
- y="307.09772">priority_queue_tag</tspan></text>
- <path
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.16226137;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="M 124.54034,382.1132 L 124.54034,360.6132 L 311.75594,359.6132 L 311.75594,382.1132"
- id="path2244" />
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect3422"
- width="141.64481"
- height="23.200001"
- x="425.73022"
- y="382.17499" />
- <text
- sodipodi:linespacing="100%"
- id="text3406"
- y="395.91092"
- x="495.3526"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- xml:space="preserve"><tspan
- sodipodi:role="line"
- id="tspan1377"
- x="495.3526"
- y="395.91092">rc_binomial_heap_tag</tspan></text>
- <rect
- y="382.17499"
- x="607.93024"
- height="23.200001"
- width="141.64481"
- id="rect3424"
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <text
- xml:space="preserve"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- x="679.15259"
- y="395.91092"
- id="text3412"
- sodipodi:linespacing="100%"><tspan
- sodipodi:role="line"
- id="tspan1379"
- x="679.15259"
- y="395.91092">binary_heap_tag</tspan></text>
- <path
- id="path3347"
- d="M 495.79886,382.13056 L 495.79886,321.40547"
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
- <rect
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1.25;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- id="rect2281"
- width="141.64481"
- height="23.200001"
- x="795.625"
- y="382.17499" />
- <text
- sodipodi:linespacing="100%"
- id="text2283"
- y="395.91092"
- x="866.84735"
- style="font-size:9.60000038;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:100%;writing-mode:lr;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;font-family:Bitstream Vera Sans"
- xml:space="preserve"><tspan
- sodipodi:role="line"
- id="tspan1359"
- x="866.84735"
- y="395.91092">thin_heap_tag</tspan></text>
- <path
- style="fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#000000;stroke-width:1.25;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="M 311.5,360 L 680,360"
- id="path2309" />
- <use
- x="0"
- y="0"
- xlink:href="#path2244"
- id="use2311"
- transform="matrix(-1,0,0,1,992.3371,0)"
- width="990"
- height="765" />
- </g>
-</svg>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test.html
deleted file mode 100644
index a4bf576ff..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test.html
+++ /dev/null
@@ -1,141 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Priority Queue Text Join Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Priority Queue Text <tt>join</tt> Timing Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with keys from an
- arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into
- two containers, then merges the containers. It uses
- <tt>join</tt> for <tt>pb_ds</tt>'s priority queues; for the
- STL's priority queues, it successively pops values from one
- container and pushes them into the other. The test measures the
- average time as a function of the number of values.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_text_join_timing.cc"><tt>priority_queue_text_join_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- data structures (see <a href="pq_design.html#pq_imp">Design::Priority
- Queues::Implementations</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and
- <a href="#NPL">NPL</a> show the results for the native priority
- queues and <tt>pb_ds</tt> 's priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc</u></a>, and <a href="pq_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NPG_res_div">
-<div id="NPG_gcc">
-<div id="NPG_priority_queue_text_join_timing_test">
-<div id="NPG_pq">
-<div id="NPG_Native_tree_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_text_join_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native tree and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPM_res_div">
-<div id="NPM_msvc">
-<div id="NPM_priority_queue_text_join_timing_test">
-<div id="NPM_pq">
-<div id="NPM_Native_tree_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_text_join_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native tree and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPL_res_div">
-<div id="NPL_local">
-<div id="NPL_priority_queue_text_join_timing_test">
-<div id="NPL_pq">
-<div id="NPL_Native_tree_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_text_join_timing_test_local.png" alt="no image" /></a></h6>NPL: Native tree and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>In this test the node-based heaps perform <tt>join</tt> in
- either logarithmic or constant time. The binary heap requires
- linear time, since the well-known heapify algorithm [<a href="references.html#clrs2001">clrs2001</a>] is linear.</p>
-<p>It would be possible to apply the heapify algorithm to the
- STL containers, if they would support iteration (which they
- don't). Barring iterators, it is still somehow possible to
- perform linear-time merge on a <tt>std::vector</tt>-based STL
- priority queue, using <tt>top()</tt> and <tt>size()</tt> (since
- they are enough to expose the underlying array), but this is
- impossible for a <tt>std::deque</tt>-based STL priority queue.
- Without heapify, the cost is super-linear.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_gcc.png
deleted file mode 100644
index a48bb3586..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_local.png
deleted file mode 100644
index 1701b4d8a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_msvc.png
deleted file mode 100644
index 0575b99c0..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_join_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html
deleted file mode 100644
index 7ece80bcf..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test.html
+++ /dev/null
@@ -1,204 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Priority Queue Text Modify (Down) Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Priority Queue Text <tt>modify</tt> Timing Test - II</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with keys from an
- arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into
- into a container then modifies each one "down" (<i>i.e.,</i> it
- makes it smaller). It uses <tt>modify</tt> for <tt>pb_ds</tt>'s
- priority queues; for the STL's priority queues, it pops values
- from a container until it reaches the value that should be
- modified, then pushes values back in. It measures the average
- time for <tt>modify</tt> as a function of the number of
- values.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_text_modify_timing.cc"><tt>priority_queue_text_modify_down_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100 f)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The main purpose of this test is to contrast <a href="priority_queue_text_modify_up_timing_test.html">Priority Queue
- Text <tt>modify</tt> Timing Test - I</a>.</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and
- <a href="#NPL">NPL</a> show the results for the native priority
- queues and <tt>pb_ds</tt> 's priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="pq_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NRTG">NRTG</a>, <a href="#NRTM">NRTM</a>, and <a href="#NRTL">NRTL</a> show the results
- for the pairing heap and thin heaps in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="pq_performance_tests.html#local"><u>local</u></a>,
- respectively,</p>
-<div id="NPG_res_div">
-<div id="NPG_gcc">
-<div id="NPG_priority_queue_text_modify_down_timing_test">
-<div id="NPG_pq">
-<div id="NPG_Native_and__tt_pb_ds_455tt__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_text_modify_down_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native and <tt>pb ds</tt> priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPM_res_div">
-<div id="NPM_msvc">
-<div id="NPM_priority_queue_text_modify_down_timing_test">
-<div id="NPM_pq">
-<div id="NPM_Native_and__tt_pb_ds_455tt__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_text_modify_down_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native and <tt>pb ds</tt> priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPL_res_div">
-<div id="NPL_local">
-<div id="NPL_priority_queue_text_modify_down_timing_test">
-<div id="NPL_pq">
-<div id="NPL_Native_and__tt_pb_ds_455tt__priority_queue__tt_modify_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_text_modify_down_timing_test_local.png" alt="no image" /></a></h6>NPL: Native and <tt>pb ds</tt> priority queue <tt>modify</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NRTG_res_div">
-<div id="NRTG_gcc">
-<div id="NRTG_priority_queue_text_modify_down_timing_test_pairing_thin">
-<div id="NRTG_pq">
-<div id="NRTG_Pairing_and_thin__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NRTG" id="NRTG"><img src="priority_queue_text_modify_down_timing_test_pairing_thin_gcc.png" alt="no image" /></a></h6>NRTG: Pairing and thin priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NRTM_res_div">
-<div id="NRTM_msvc">
-<div id="NRTM_priority_queue_text_modify_down_timing_test_pairing_thin">
-<div id="NRTM_pq">
-<div id="NRTM_Pairing_and_thin__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NRTM" id="NRTM"><img src="priority_queue_text_modify_down_timing_test_pairing_thin_msvc.png" alt="no image" /></a></h6>NRTM: Pairing and thin priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NRTL_res_div">
-<div id="NRTL_local">
-<div id="NRTL_priority_queue_text_modify_down_timing_test_pairing_thin">
-<div id="NRTL_pq">
-<div id="NRTL_Pairing_and_thin__priority_queue__tt_modify_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NRTL" id= "NRTL"><img src="priority_queue_text_modify_down_timing_test_pairing_thin_local.png" alt="no image" /></a></h6>NRTL: Pairing and thin priority queue <tt>modify</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>Most points in these results are similar to <a href="priority_queue_text_modify_up_timing_test.html">Priority Queue
- Text <tt>modify</tt> Timing Test - I</a>.</p>
-<p>It is interesting to note, however, that as opposed to that
- test, a thin heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> with
- <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>) is
- outperformed by a pairing heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> with
- <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>).
- In this case, both heaps essentially perform an <tt>erase</tt>
- operation followed by a <tt>push</tt> operation. As the other
- tests show, a pairing heap is usually far more efficient than a
- thin heap, so this is not surprising.</p>
-<p>Most algorithms that involve priority queues increase values
- (in the sense of the priority queue's comparison functor), and
- so <a href="priority_queue_text_modify_up_timing_test.html">Priority Queue
- Text <tt>modify</tt> Timing Test - I</a> is more interesting
- than this test.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_gcc.png
deleted file mode 100644
index 74cbc6523..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_local.png
deleted file mode 100644
index 2fa9c7988..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_msvc.png
deleted file mode 100644
index 20b663736..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_gcc.png
deleted file mode 100644
index ca901831e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_local.png
deleted file mode 100644
index 977d16718..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_msvc.png
deleted file mode 100644
index bf68bf992..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_down_timing_test_pairing_thin_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test.html
deleted file mode 100644
index 72a1e0a75..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test.html
+++ /dev/null
@@ -1,222 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Priority Queue Text Modify (Up) Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Priority Queue Text <tt>modify</tt> Timing Test - I</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with keys from an
- arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into
- into a container then modifies each one "up" (<i>i.e.,</i> it
- makes it larger). It uses <tt>modify</tt> for <tt>pb_ds</tt>'s
- priority queues; for the STL's priority queues, it pops values
- from a container until it reaches the value that should be
- modified, then pushes values back in. It measures the average
- time for <tt>modify</tt> as a function of the number of
- values.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_text_modify_timing.cc"><tt>priority_queue_text_modify_up_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100 t)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- data structures (see <a href="pq_design.html#pq_imp">Design::Priority
- Queues::Implementations</a>) for graph algorithms settings.
- Note that making an arbitrary value larger (in the sense of the
- priority queue's comparison functor) corresponds to
- decrease-key in standard graph algorithms [<a href="references.html#clrs2001">clrs2001</a>].</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and
- <a href="#NPL">NPL</a> show the results for the native priority
- queues and <tt>pb_ds</tt> 's priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="pq_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NRTG">NRTG</a>, <a href="#NRTM">NRTM</a>, and <a href="#NRTL">NRTL</a> show the results
- for the pairing heap and thin heaps in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="pq_performance_tests.html#local"><u>local</u></a>,
- respectively,</p>
-<div id="NPG_res_div">
-<div id="NPG_gcc">
-<div id="NPG_priority_queue_text_modify_up_timing_test">
-<div id="NPG_pq">
-<div id="NPG_Native_and__tt_pb_ds_455tt__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_text_modify_up_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native and <tt>pb ds</tt> priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPM_res_div">
-<div id="NPM_msvc">
-<div id="NPM_priority_queue_text_modify_up_timing_test">
-<div id="NPM_pq">
-<div id="NPM_Native_and__tt_pb_ds_455tt__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_text_modify_up_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native and <tt>pb ds</tt> priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPL_res_div">
-<div id="NPL_local">
-<div id="NPL_priority_queue_text_modify_up_timing_test">
-<div id="NPL_pq">
-<div id="NPL_Native_and__tt_pb_ds_455tt__priority_queue__tt_modify_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_text_modify_up_timing_test_local.png" alt="no image" /></a></h6>NPL: Native and <tt>pb ds</tt> priority queue <tt>modify</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NRTG_res_div">
-<div id="NRTG_gcc">
-<div id="NRTG_priority_queue_text_modify_up_timing_test_pairing_thin">
-<div id="NRTG_pq">
-<div id="NRTG_Pairing_and_thin__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NRTG" id="NRTG"><img src="priority_queue_text_modify_up_timing_test_pairing_thin_gcc.png" alt="no image" /></a></h6>NRTG: Pairing and thin priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NRTM_res_div">
-<div id="NRTM_msvc">
-<div id="NRTM_priority_queue_text_modify_up_timing_test_pairing_thin">
-<div id="NRTM_pq">
-<div id="NRTM_Pairing_and_thin__priority_queue__tt_modify_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NRTM" id="NRTM"><img src="priority_queue_text_modify_up_timing_test_pairing_thin_msvc.png" alt="no image" /></a></h6>NRTM: Pairing and thin priority queue <tt>modify</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NRTL_res_div">
-<div id="NRTL_local">
-<div id="NRTL_priority_queue_text_modify_up_timing_test_pairing_thin">
-<div id="NRTL_pq">
-<div id="NRTL_Pairing_and_thin__priority_queue__tt_modify_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NRTL" id= "NRTL"><img src="priority_queue_text_modify_up_timing_test_pairing_thin_local.png" alt="no image" /></a></h6>NRTL: Pairing and thin priority queue <tt>modify</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>As noted above, increasing an arbitrary value (in the sense
- of the priority queue's comparison functor) is very common in
- graph-related algorithms. In this case, a thin heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> with
- <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>)
- outperforms a pairing heap (<a href="priority_queue.html"><tt>priority_queue</tt></a> with
- <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>).
- Conversely, <a href="priority_queue_text_push_timing_test.html">Priority Queue Text
- <tt>push</tt> Timing Test</a>, <a href="priority_queue_text_push_pop_timing_test.html">Priority Queue
- Text <tt>push</tt> and <tt>pop</tt> Timing Test</a>, <a href="priority_queue_random_int_push_timing_test.html">Priority
- Queue Random Integer <tt>push</tt> Timing Test</a>, and
- <a href="priority_queue_random_int_push_pop_timing_test.html">Priority
- Queue Random Integer <tt>push</tt> and <tt>pop</tt> Timing
- Test</a> show that the situation is reversed for other
- operations. It is not clear when to prefer one of these two
- different types.</p>
-<p>In this test <tt>pb_ds</tt>'s binary heaps effectively
- perform modify in linear time. As explained in <a href="pq_design.html#pq_traits">Priority Queue Design::Traits</a>,
- given a valid point-type iterator, a binary heap can perform
- <tt>modify</tt> logarithmically. The problem is that binary
- heaps invalidate their find iterators with each modifying
- operation, and so the only way to obtain a valid point-type
- iterator is to iterate using a range-type iterator until
- finding the appropriate value, then use the range-type iterator
- for the <tt>modify</tt> operation.</p>
-<p>The explanation for the STL's priority queues' performance
- is similar to that in <a href="priority_queue_text_join_timing_test.html">Priority Queue Text
- <tt>join</tt> Timing Test</a>.</p>
-<p><a href="pq_performance_tests.html#pq_observations">Priority-Queue
- Performance Tests::Observations</a> discusses this further and
- summarizes.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_gcc.png
deleted file mode 100644
index d9dedc20c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_local.png
deleted file mode 100644
index 31575b452..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_msvc.png
deleted file mode 100644
index 4005547c8..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_gcc.png
deleted file mode 100644
index 1aa5aba94..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_local.png
deleted file mode 100644
index b878dde66..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_msvc.png
deleted file mode 100644
index 740594384..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_modify_up_timing_test_pairing_thin_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test.html
deleted file mode 100644
index 2545fc07d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test.html
+++ /dev/null
@@ -1,143 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Priority Queue Text Pop Memory Use Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Priority Queue Text <tt>pop</tt> Memory Use Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with keys from an
- arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into
- a container, then pops them until only one is left in the
- container. It measures the memory use as a function of the
- number of values pushed to the container.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_text_pop_mem_usage.cc"><tt>priority_queue_text_pop_mem_usage_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- data structures (see <a href="pq_design.html#pq_imp">Design::Priority
- Queues::Implementations</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and
- <a href="#NPL">NPL</a> show the results for the native priority
- queues and <tt>pb_ds</tt> 's priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="pq_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NPG_res_div">
-<div id="NPG_gcc">
-<div id="NPG_priority_queue_text_pop_mem_usage_test">
-<div id="NPG_pq">
-<div id="NPG_Native_and__tt_pb_ds_455tt__priority_queue__tt_pop_455tt__memory-use_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_text_pop_mem_usage_test_gcc.png" alt="no image" /></a></h6>NPG: Native and <tt>pb ds</tt> priority queue <tt>pop</tt> memory-use test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPM_res_div">
-<div id="NPM_msvc">
-<div id="NPM_priority_queue_text_pop_mem_usage_test">
-<div id="NPM_pq">
-<div id="NPM_Native_and__tt_pb_ds_455tt__priority_queue__tt_pop_455tt__memory-use_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_text_pop_mem_usage_test_msvc.png" alt="no image" /></a></h6>NPM: Native and <tt>pb ds</tt> priority queue <tt>pop</tt> memory-use test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPL_res_div">
-<div id="NPL_local">
-<div id="NPL_priority_queue_text_pop_mem_usage_test">
-<div id="NPL_pq">
-<div id="NPL_Native_and__tt_pb_ds_455tt__priority_queue__tt_pop_455tt__memory-use_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_text_pop_mem_usage_test_local.png" alt="no image" /></a></h6>NPL: Native and <tt>pb ds</tt> priority queue <tt>pop</tt> memory-use test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>The priority queue implementations (excluding the STL's) use
- memory proportionally to the number of values they hold:
- node-based implementations (<i>e.g.</i>, a pairing heap) do so
- naturally; <tt>pb_ds</tt>'s binary heap de-allocates memory when
- a certain lower threshold is exceeded.</p>
-<p>Note from <a href="priority_queue_text_push_pop_timing_test.html">Priority Queue
- Text <tt>push</tt> and <tt>pop</tt> Timing Test</a> and
- <a href="priority_queue_random_int_push_pop_timing_test.html">Priority
- Queue Random Integer <tt>push</tt> and <tt>pop</tt> Timing
- Test</a> that this does not impede performance compared to the
- STL's priority queues.</p>
-<p>(See <a href="hash_random_int_erase_mem_usage_test.html">Hash-Based Erase
- Memory Use Test</a> for a similar phenomenon regarding priority
- queues.)</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_gcc.png
deleted file mode 100644
index 2c1918d06..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_local.png
deleted file mode 100644
index c1413fc93..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_msvc.png
deleted file mode 100644
index 9717f498b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_pop_mem_usage_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test.html
deleted file mode 100644
index 3c143fe5a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test.html
+++ /dev/null
@@ -1,209 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Priority Queue Text Push Pop Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Priority Queue Text <tt>push</tt> and <tt>pop</tt> Timing
- Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with keys from an
- arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into
- a container using <tt>push</tt> , then removes them using
- <tt>pop</tt> . It measures the average time for <tt>push</tt>
- as a function of the number of values.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_text_push_pop_timing.cc"><tt>
- priority_queue_text_push_pop_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- data structures (see <a href="pq_design.html#pq_imp">Design::Priority
- Queues::Implementations</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and
- <a href="#NPL">NPL</a> show the results for the native priority
- queues and <tt>pb_ds</tt> 's priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="pq_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NBRG">NBRG</a>, <a href="#NBRM">NBRM</a>, and <a href="#NBRL">NBRL</a> show the results
- for the native priority queues and <tt>pb_ds</tt>'s pairing
- queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="pq_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NPG_res_div">
-<div id="NPG_gcc">
-<div id="NPG_priority_queue_text_push_pop_timing_test">
-<div id="NPG_pq">
-<div id="NPG_Native_tree_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__and__tt_pop_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_text_push_pop_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native tree and <tt>pb ds</tt> priority queue <tt>push</tt> and <tt>pop</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPM_res_div">
-<div id="NPM_msvc">
-<div id="NPM_priority_queue_text_push_pop_timing_test">
-<div id="NPM_pq">
-<div id="NPM_Native_tree_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__and__tt_pop_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_text_push_pop_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native tree and <tt>pb ds</tt> priority queue <tt>push</tt> and <tt>pop</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPL_res_div">
-<div id="NPL_local">
-<div id="NPL_priority_queue_text_push_pop_timing_test">
-<div id="NPL_pq">
-<div id="NPL_Native_tree_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__and__tt_pop_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_text_push_pop_timing_test_local.png" alt="no image" /></a></h6>NPL: Native tree and <tt>pb ds</tt> priority queue <tt>push</tt> and <tt>pop</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NBRG_res_div">
-<div id="NBRG_gcc">
-<div id="NBRG_pairing_priority_queue_text_push_pop_timing_test">
-<div id="NBRG_pq">
-<div id="NBRG_Native_tree_and__tt_pb_ds_455tt__pairing_priority_queue__tt_push_455tt__and__tt_pop_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBRG" id="NBRG"><img src="pairing_priority_queue_text_push_pop_timing_test_gcc.png" alt="no image" /></a></h6>NBRG: Native tree and <tt>pb ds</tt> pairing priority queue <tt>push</tt> and <tt>pop</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NBRM_res_div">
-<div id="NBRM_msvc">
-<div id="NBRM_pairing_priority_queue_text_push_pop_timing_test">
-<div id="NBRM_pq">
-<div id="NBRM_Native_tree_and__tt_pb_ds_455tt__pairing_priority_queue__tt_push_455tt__and__tt_pop_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBRM" id="NBRM"><img src="pairing_priority_queue_text_push_pop_timing_test_msvc.png" alt="no image" /></a></h6>NBRM: Native tree and <tt>pb ds</tt> pairing priority queue <tt>push</tt> and <tt>pop</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NBRL_res_div">
-<div id="NBRL_local">
-<div id="NBRL_pairing_priority_queue_text_push_pop_timing_test">
-<div id="NBRL_pq">
-<div id="NBRL_Native_tree_and__tt_pb_ds_455tt__pairing_priority_queue__tt_push_455tt__and__tt_pop_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBRL" id= "NBRL"><img src="pairing_priority_queue_text_push_pop_timing_test_local.png" alt="no image" /></a></h6>NBRL: Native tree and <tt>pb ds</tt> pairing priority queue <tt>push</tt> and <tt>pop</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>These results are very similar to <a href="priority_queue_text_push_timing_test.html">Priority Queue Text
- <tt>push</tt> Timing Test</a>. As stated there, pairing heaps
- (<a href="priority_queue.html"><tt>priority_queue</tt></a> with
- <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>)
- are most suited for <tt>push</tt> and <tt>pop</tt> sequences of
- non-primitive types such as strings. Observing these two tests,
- one can note that a pairing heap outperforms the others in
- terms of <tt>push</tt> operations, but equals binary heaps
- (<a href="priority_queue.html"><tt>priority_queue</tt></a> with
- <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>) if
- the number of <tt>push</tt> and <tt>pop</tt> operations is
- equal. As the number of <tt>pop</tt> operations is at most
- equal to the number of <tt>push</tt> operations, pairing heaps
- are better in this case. See <a href="priority_queue_random_int_push_pop_timing_test.html">Priority
- Queue Random Integer <tt>push</tt> and <tt>pop</tt> Timing
- Test</a> for a case which is different.</p>
-<p><a href="pq_performance_tests.html#pq_observations">Priority-Queue
- Performance Tests::Observations</a> discusses this further and
- summarizes.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_gcc.png
deleted file mode 100644
index d4886ae59..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_local.png
deleted file mode 100644
index a7c5f8987..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_msvc.png
deleted file mode 100644
index a5720402b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_pop_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test.html
deleted file mode 100644
index 542eb913c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test.html
+++ /dev/null
@@ -1,219 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Priority Queue Text Push Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Priority Queue Text <tt>push</tt> Timing Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with keys from an
- arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into
- a container using <tt>push</tt> . It measures the average time
- for <tt>push</tt> as a function of the number of values
- pushed.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/priority_queue_text_push_timing.cc"><tt>priority_queue_text_push_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- data structures (see <a href="pq_design.html#pq_imp">Design::Priority
- Queues::Implementations</a>).</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NPG">NPG</a>, <a href="#NPM">NPM</a>, and
- <a href="#NPL">NPL</a> show the results for the native priority
- queues and <tt>pb_ds</tt> 's priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="pq_performance_tests.html#local"><u>local</u></a>,
- respectively; Figures <a href="#NBRG">NBRG</a>, <a href="#NBRM">NBRM</a>, and <a href="#NBRL">NBRL</a> shows the
- results for the binary-heap based native priority queues and
- <tt>pb_ds</tt>'s pairing-heap priority queues in <a href="pq_performance_tests.html#gcc"><u>g++</u></a>, <a href="pq_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="pq_performance_tests.html#local"><u>local</u></a>,
- respectively</p>
-<div id="NPG_res_div">
-<div id="NPG_gcc">
-<div id="NPG_priority_queue_text_push_timing_test">
-<div id="NPG_pq">
-<div id="NPG_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPG" id="NPG"><img src="priority_queue_text_push_timing_test_gcc.png" alt="no image" /></a></h6>NPG: Native and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPM_res_div">
-<div id="NPM_msvc">
-<div id="NPM_priority_queue_text_push_timing_test">
-<div id="NPM_pq">
-<div id="NPM_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPM" id="NPM"><img src="priority_queue_text_push_timing_test_msvc.png" alt="no image" /></a></h6>NPM: Native and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-rc_binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="rc_binomial_heap_tag.html"><tt>rc_binomial_heap_tag</tt></a>
-</li>
-<li>
-binary_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binary_heap_tag.html"><tt>binary_heap_tag</tt></a>
-</li>
-<li>
-binomial_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="binomial_heap_tag.html"><tt>binomial_heap_tag</tt></a>
-</li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPL_res_div">
-<div id="NPL_local">
-<div id="NPL_priority_queue_text_push_timing_test">
-<div id="NPL_pq">
-<div id="NPL_Native_and__tt_pb_ds_455tt__priority_queue__tt_push_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPL" id= "NPL"><img src="priority_queue_text_push_timing_test_local.png" alt="no image" /></a></h6>NPL: Native and <tt>pb ds</tt> priority queue <tt>push</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NBRG_res_div">
-<div id="NBRG_gcc">
-<div id="NBRG_pairing_priority_queue_text_push_timing_test">
-<div id="NBRG_pq">
-<div id="NBRG_Native_and__tt_pb_ds_455tt__pairing_priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBRG" id="NBRG"><img src="pairing_priority_queue_text_push_timing_test_gcc.png" alt="no image" /></a></h6>NBRG: Native and <tt>pb ds</tt> pairing priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NBRM_res_div">
-<div id="NBRM_msvc">
-<div id="NBRM_pairing_priority_queue_text_push_timing_test">
-<div id="NBRM_pq">
-<div id="NBRM_Native_and__tt_pb_ds_455tt__pairing_priority_queue__tt_push_455tt__timing_test"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBRM" id="NBRM"><img src="pairing_priority_queue_text_push_timing_test_msvc.png" alt="no image" /></a></h6>NBRM: Native and <tt>pb ds</tt> pairing priority queue <tt>push</tt> timing test - <a href="pq_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_pq_deque-
-<tt>std::priority_queue</tt> adapting <tt>std::deque</tt></li>
-<li>
-n_pq_vector-
-<tt>std::priority_queue</tt> adapting <tt>std::vector</tt></li>
-<li>
-pairing_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>
-</li>
-<li>
-thin_heap-
-<a href="priority_queue.html"><tt>priority_queue</tt></a>
- with <tt>Tag</tt> = <a href="thin_heap_tag.html"><tt>thin_heap_tag</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NBRL_res_div">
-<div id="NBRL_local">
-<div id="NBRL_pairing_priority_queue_text_push_timing_test">
-<div id="NBRL_pq">
-<div id="NBRL_Native_and__tt_pb_ds_455tt__pairing_priority_queue__tt_push_455tt__timing_test"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NBRL" id= "NBRL"><img src="pairing_priority_queue_text_push_timing_test_local.png" alt="no image" /></a></h6>NBRL: Native and <tt>pb ds</tt> pairing priority queue <tt>push</tt> timing test - <a href = "pq_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>Pairing heaps (<a href="priority_queue.html"><tt>priority_queue</tt></a> with
- <tt>Tag</tt> = <a href="pairing_heap_tag.html"><tt>pairing_heap_tag</tt></a>)
- are the most suited for sequences of <tt>push</tt> and
- <tt>pop</tt> operations of non-primitive types (<i>e.g.</i>
-<tt>std::string</tt>s). (see also <a href="priority_queue_text_push_pop_timing_test.html">Priority Queue
- Text <tt>push</tt> and <tt>pop</tt> Timing Test</a>.) They are
- less constrained than binomial heaps, <i>e.g.</i>, and since
- they are node-based, they outperform binary heaps. (See
- <a href="priority_queue_random_int_push_timing_test.html">Priority
- Queue Random Integer <tt>push</tt> Timing Test</a> for the case
- of primitive types.)</p>
-<p>The STL's priority queues do not seem to perform well in
- this case: the <tt>std::vector</tt> implementation needs to
- perform a logarithmic sequence of string operations for each
- operation, and the deque implementation is possibly hampered by
- its need to manipulate a relatively-complex type (deques
- support a <i>O(1)</i> <tt>push_front</tt>, even though it is
- not used by <tt>std::priority_queue</tt>.)</p>
-<p><a href="pq_performance_tests.html#pq_observations">Priority-Queue
- Performance Tests::Observations</a> discusses this further and
- summarizes.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_gcc.png
deleted file mode 100644
index 8895f507c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_local.png
deleted file mode 100644
index da7297bff..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_msvc.png
deleted file mode 100644
index ff39ca37d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/priority_queue_text_push_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/quadratic_probe_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/quadratic_probe_fn.html
deleted file mode 100644
index 00367dac8..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/quadratic_probe_fn.html
+++ /dev/null
@@ -1,141 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>quadratic_probe_fn Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>quadratic_probe_fn</tt> Interface</h1>
-
- <p>A probe sequence policy using square increments.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/hash_policy.hpp"><tt>hash_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Size_Type42920436" id=
-"Size_Type42920436"><b>typename</b> Size_Type </a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
-
- <td>size_t</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Size_Type42920436"><tt>Size_Type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link4" id="link4">Public Methods</a></h2>
-
- <h3><a name="link5" id="link5">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class=
-"c2"><tt>quadratic_probe_fn</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link6" id="link6">Protected Methods</a></h2>
-
- <h3><a name="link7" id="link7">Offset Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- <b>operator</b>()
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> i) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the <span class="c1"><tt>i</tt></span>-th
- offset from the hash value.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_gcc.png
deleted file mode 100644
index 61962704f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_local.png
deleted file mode 100644
index 83105202a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_msvc.png
deleted file mode 100644
index 2206cef5a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/random_int_find_find_timing_test_tree_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/range_invalidation_guarantee.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/range_invalidation_guarantee.html
deleted file mode 100644
index 7bfba19e8..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/range_invalidation_guarantee.html
+++ /dev/null
@@ -1,52 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>range_invalidation_guarantee Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>range_invalidation_guarantee</tt> Interface</h1>
-
- <p>Signifies an invalidation guarantee that includes all those
- of its base, and additionally, that any range-type iterator
- (including the returns of begin() and end()) is in the correct
- relative positions to other range-type iterators as long as its
- corresponding entry has not be erased, regardless of
- modifications to the container object.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="point_invalidation_guarantee.html"><span class=
-"c2"><tt>point_invalidation_guarantee</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rationale_null_node_updator.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rationale_null_node_updator.png
deleted file mode 100644
index 438748915..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rationale_null_node_updator.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rb_tree_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rb_tree_tag.html
deleted file mode 100644
index 2adbd09bf..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rb_tree_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>rb_tree_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>rb_tree_tag</tt> Interface</h1>
-
- <p>Red-black tree data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="tree_tag.html"><span class=
-"c2"><tt>tree_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rc_binomial_heap_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rc_binomial_heap_tag.html
deleted file mode 100644
index 1a4ba9f2e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/rc_binomial_heap_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>rc_binomial_heap_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>rc_binomial_heap_tag</tt> Interface</h1>
-
- <p>Redundant-counter binomial-heap data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="priority_queue_tag.html"><span class=
-"c2"><tt>priority_queue_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/references.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/references.html
deleted file mode 100644
index b96827bd3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/references.html
+++ /dev/null
@@ -1,258 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>References</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>References</h1>
-
- <ol>
- <li>[<a name="abrahams97exception" id=
- "abrahams97exception">abrahams97exception</a>] Dave Abrahams,
- STL Exception Handling Contract, <a href=
- "http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1075.pdf">
- http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/1997/N1075.pdf</a></li>
-
- <li>[<a name="alexandrescu01modern" id=
- "alexandrescu01modern">alexandrescu01modern</a>] Andrei
- Alexandrescu, <i>Modern C++ Design: Generic Programming and
- Design Patterns Applied</i>, Addison-Wesley Publishing
- Company, 2001</li>
-
- <li>[<a name="andrew04mtf" id="andrew04mtf">andrew04mtf</a>]
- K. Andrew and D. Gleich, "MTF, Bit, and COMB: A Guide to
- Deterministic and Randomized Algorithms for the List Update
- Problem"</li>
-
- <li>[<a name="austern00noset" id=
- "austern00noset">austern00noset</a>] Matthew Austern, "Why
- You shouldn't use <tt>set</tt> - and What You Should Use
- Instead", C++ Report, April, 2000</li>
-
- <li>[<a name="austern01htprop" id=
- "austern01htprop">austern01htprop</a>] Matthew Austern, "A
- Proposal to Add Hashtables to the Standard Library", <a href=
- "http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1326l.html">
- http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1326l.html</a></li>
-
- <li>[<a name="austern98segmented" id=
- "austern98segmented">austern98segmented</a>] Matthew Austern,
- "Segmented iterators and hierarchical algorithms", Generic
- Programming, April 1998, pp. 80-90</li>
-
- <li>[<a name="boost_timer" id="boost_timer">boost_timer</a>],
- "Boost timer library", <a href=
- "http://www.boost.org/">http://www.boost.org</a> by Beman
- Dawes</li>
-
- <li>[<a name="boost_pool" id="boost_pool">boost_pool</a>],
- "Boost pool library", <a href=
- "http://www.boost.org/">http://www.boost.org</a> by Stephen
- Cleary</li>
-
- <li>[<a name="boost_type_traits" id=
- "boost_type_traits">boost_type_traits</a>], "Boost
- <tt>type_traits</tt> library", <a href=
- "http://www.boost.org/">http://www.boost.org</a> by John
- Maddock, Steve Cleary, <i>et. al.</i></li>
-
- <li>[<a name="brodal96priority" id=
- "brodal96priority">brodal96priority</a>] Gerth Stolting
- Brodal, <a href=
- "http://portal.acm.org/citation.cfm?id=313883">Worst-case
- efficient priority queues</a></li>
-
- <li>[<a name="bulka99efficient" id=
- "bulka99efficient">bulka99efficient</a>] D. Bulka, and D.
- Mayhew, "Efficient C++ Programming Techniques.",
- Addison-Wesley Publishing Company, Addison-Wesley, 1997</li>
-
- <li>[<a name="clrs2001" id="clrs2001">clrs2001</a>] T. H.
- Cormen, C. E., Leiserson, R. L. Rivest, C. and Stein,
- "Introduction to Algorithms, 2nd ed.", MIT Press, 2001</li>
-
- <li>[<a name="dinkumware_stl" id=
- "dinkumware_stl">dinkumware_stl</a>], "Dinkumware C++ Library
- Reference", <a href=
- "http://www.dinkumware.com/htm_cpl/index.html">http://www.dinkumware.com/htm_cpl/index.html</a></li>
-
- <li>[<a name="dubhashi98neg" id=
- "dubhashi98neg">dubhashi98neg</a>] D. Dubashi, and D. Ranjan,
- "Balls and bins: A study in negative dependence.", Random
- Structures and Algorithms 13, 2 (1998), 99-124</li>
-
- <li>[<a name="fagin79extendible" id=
- "fagin79extendible">fagin79extendible</a>] R. Fagin, J.
- Nievergelt, N. Pippenger, and H. R. Strong, "Extendible
- hashing - a fast access method for dynamic files", ACM Trans.
- Database Syst. 4, 3 (1979), 315-344</li>
-
- <li>[<a name="filliatre2000ptset" id=
- "filliatre2000ptset">filliatre2000ptset</a>], J. C.
- Filliatre, "Ptset: Sets of integers implemented as Patricia
- trees", <a href=
- "http://www.lri.fr/~filliatr/ftp/ocaml/misc/ptset.ml">http://www.lri.fr/~filliatr/ftp/ocaml/misc/ptset.ml</a></li>
-
- <li>[<a name="fredman86pairing" id=
- "fredman86pairing">fredman86pairing</a>], M. L. Fredman, R
- Sedgewick, D. D. Sleator, R. E. Tarjan, <a href=
- "http://www.cs.cmu.edu/~sleator/papers/pairing-heaps.pdf">The
- pairing heap: a new form of self-adjusting heap</a></li>
-
- <li>[<a name="gamma95designpatterns" id=
- "gamma95designpatterns">gamma95designpatterns</a>] E. Gamma,
- R. Helm, R. Johnson, and J. Vlissides, "Design Patterns -
- Elements of Reusable Object-Oriented Software",
- Addison-Wesley Publishing Company, Addison-Wesley, 1995</li>
-
- <li>[<a name="garg86order" id="garg86order">garg86order</a>]
- A. K. Garg and C. C. Gotlieb, "Order-preserving key
- transformations", Trans. Database Syst. 11, 2 (1986),
- 213-234</li>
-
- <li>[<a name="hyslop02making" id=
- "hyslop02making">hyslop02making</a>] J. Hyslop, and H.
- Sutter, "Making a real hash of things", C++ Report, May
- 2002</li>
-
- <li>[<a name="jossutis01stl" id=
- "jossutis01stl">jossutis01stl</a>] N. M. Jossutis, "The C++
- Standard Library - A Tutorial and Reference", Addison-Wesley
- Publishing Company, Addison-Wesley, 2001</li>
-
- <li>[<a name="kt99fat_heaps" id=
- "kt99fat_heaps">kt99fat_heas</a>] Haim Kaplan and Robert E.
- Tarjan, <a href=
- "http://www.cs.princeton.edu/research/techreps/TR-597-99">New
- Heap Data Structures</a></li>
-
- <li>[<a name="kleft00sets" id="kleft00sets">kleft00sets</a>]
- Klaus Kleft and Angelika Langer, "Are Set Iterators Mutable
- or Immutable?", C/C++ Users Jornal, October 2000</li>
-
- <li>[<a name="knuth98sorting" id=
- "knuth98sorting">knuth98sorting</a>] D. E. Knuth, "The Art of
- Computer Programming - Sorting and Searching", Addison-Wesley
- Publishing Company, Addison-Wesley, 1998</li>
-
- <li>[<a name="liskov98data" id=
- "liskov98data">liskov98data</a>] B. Liskov, "Data abstraction
- and hierarchy", SIGPLAN Notices 23, 5 (May 1998)</li>
-
- <li>[<a name="litwin80lh" id="litwin80lh">litwin80lh</a>] W.
- Litwin, "Linear hashing: A new tool for file and table
- addressing", Proceedings of International Conference on Very
- Large Data Bases (June 1980), pp. 212-223</li>
-
- <li>[<a name="maverik_lowerbounds" id=
- "maverik_lowerbounds">maverik_lowerbounds</a>] Maverik Woo,
- <a href=
- "http://magic.aladdin.cs.cmu.edu/2005/08/01/deamortization-part-2-binomial-heaps/">
- Deamortization - Part 2: Binomial Heaps</a></li>
-
- <li>[<a name="metrowerks_stl" id=
- "metrowerks_stl">metrowerks_stl</a>], "Metrowerks CodeWarrior
- Pro 7 MSL C++ Reference Manual",</li>
-
- <li>[<a name="meyers96more" id=
- "meyers96more">meyers96more</a>] S. Meyers, "More Effective
- C++: 35 New Ways to Improve Your Programs and Designs - 2nd
- ed.", Addison-Wesley Publishing Company, Addison-Wesley,
- 1996</li>
-
- <li>[<a name="meyers00nonmember" id=
- "meyers00nonmember">meyers00nonmember</a>] S. Meyers, "How
- Non-Member Functions Improve Encapsulation", C/C++ Users
- Journal, 2000</li>
-
- <li>[<a name="meyers01stl" id="meyers01stl">meyers01stl</a>]
- S. Meyers, "Effective STL: 50 Specific Ways to Improve Your
- Use of the Standard Template Library", Addison-Wesley
- Publishing Company, Addison-Wesley, 2001</li>
-
- <li>[<a name="meyers02both" id=
- "meyers02both">meyers02both</a>] S. Meyers, "Class Template,
- Member Template - or Both?", C/C++ Users Journal, 2003</li>
-
- <li>[<a name="motwani95random" id=
- "motwani95random">motwani95random</a>] R. Motwani, and P.
- Raghavan, "Randomized Algorithms", Cambridge University
- Press</li>
-
- <li>[<a name="mscom" id="mscom">mscom</a>] <a href=
- "http://www.microsoft.com/com">COM: Component Model Object
- Technologies</a></li>
-
- <li>[<a name="musser95rationale" id=
- "musser95rationale">musser95rationale</a>], David R. Musser,
- "Rationale for Adding Hash Tables to the C++ Standard
- Template Library"</li>
-
- <li>[<a name="musser96stltutorial" id=
- "musser96stltutorial">musser96stltutorial</a>] D. R. Musser
- and A. Saini, "STL Tutorial and Reference Guide",
- Addison-Wesley Publishing Company, Addison-Wesley, 1996</li>
-
- <li>[<a name="nelson96stlpq" id=
- "nelson96stlpq">nelson96stlpql</a>] Mark Nelson, <a href=
- "http://www.dogma.net/markn/articles/pq_stl/priority.htm">Priority
- Queues and the STL</a>, Dr. Dobbs Journal, January, 1996</li>
-
- <li>[<a name="okasaki98mereable" id=
- "okasaki98mereable">okasaki98mereable</a>] C. Okasaki and A.
- Gill, "Fast mergeable integer maps", In Workshop on ML, pages
- 77--86, September 1998. 95</li>
-
- <li>[<a name="sgi_stl" id="sgi_stl">sgi_stl</a>] SGI,
- "Standard Template Library Programmer's Guide", <a href=
- "http://www.sgi.com/tech/stl">http://www.sgi.com/tech/stl</a></li>
-
- <li>[<a name="select_man" id="select_man">select_man</a>]
- <a href=
- "http://www.scit.wlv.ac.uk/cgi-bin/mansec?3C+select"><tt>select</tt>
- man page.</a></li>
-
- <li>[<a name="sleator84amortized" id=
- "sleator84amortized">sleator84amortized</a>] D. D. Sleator
- and R. E. Tarjan, "Amortized Efficiency of List Update
- Problems", ACM Symposium on Theory of Computing, 1984</li>
-
- <li>[<a name="sleator85self" id=
- "sleator85self">sleator85self</a>] D. D. Sleator and R. E.
- Tarjan, "Self-Adjusting Binary Search Trees", ACM Symposium
- on Theory of Computing, 1985</li>
-
- <li>[<a name="stepanov94standard" id=
- "stepanov94standard">stepanov94standard</a>] A. A. Stepanov
- and M. Lee", "The Standard Template Library"</li>
-
- <li>[<a name="stroustrup97cpp" id=
- "stroustrup97cpp">stroustrup97cpp</a>] Bjarne Stroustrup,
- <i>The C++ Programming Langugage -3rd ed.</i>, Addison-Wesley
- Publishing Company,Reading, MA, USA, 1997</li>
-
- <li>[<a name="vandevoorde2002cpptemplates" id=
- "vandevoorde2002cpptemplates">vandevoorde2002cpptemplates</a>]
- D. Vandevoorde, and N. M. Josuttis, "C++ Templates: The
- Complete Guide", Addison-Wesley Publishing Company,
- Addison-Wesley, 2002</li>
-
- <li>[<a name="wickland96thirty" id=
- "wickland96thirty">wickland96thirty</a>] C. A. Wickland,
- "Thirty Years Among the Dead", National Psychological
- Institute, Los Angeles, 1996,<a href=
- "http://myweb.wvnet.edu/~gsa00121/books/amongdead30.zip">http://myweb.wvnet.edu/gsa00121/books/amongdead30.zip</a></li>
- </ol>
- <hr />
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_error.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_error.html
deleted file mode 100644
index 6aab88c15..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_error.html
+++ /dev/null
@@ -1,50 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
-<title>resize_error Interface</title>
-<meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
-</head>
-
-<body>
-<div id="page">
-<h1><tt>resize_error</tt> Interface</h1>
-
-<p>A container cannot be resized.</p>
-
-<p>Exception thrown when a size policy cannot supply an
- adequate size for an external resize.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/exception.hpp"><tt>exception.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- <a href="exceptions.html"><span class=
- "c2"><tt>resize_error</tt></span></a>
- </pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
- </body>
- </html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_policy_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_policy_cd.png
deleted file mode 100644
index 338e33c15..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/resize_policy_cd.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/restoring_node_invariants.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/restoring_node_invariants.png
deleted file mode 100644
index 33ba84bfe..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/restoring_node_invariants.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_probe_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_probe_fn.html
deleted file mode 100644
index 51dccce5c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_probe_fn.html
+++ /dev/null
@@ -1,152 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>sample_probe_fn Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>sample_probe_fn</tt> Interface</h1>
-
- <p>A sample probe policy.</p>
-
- <p>This class serves to show the interface a probe functor
- needs to support.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/hash_fn/sample_probe_fn.hpp"><tt>sample_probe_fn.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Public Types and
- Constants</a></h2>
-
- <h3><a name="link2" id="link2">General definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-size_t, e.g.
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Methods</a></h2>
-
- <h3><a name="link4" id="link4">Constructors, destructor, and
- related.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_probe_fn
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
-
- <p>Must be default constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_probe_fn
- (<b>const</b> sample_probe_fn &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
-
- <p>Must be copy constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- swap
- (sample_probe_fn &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
-
- <p>Must be swappable (if there is such a word).</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Protected Methods</a></h2>
-
- <h3><a name="link6" id="link6">Offset methods.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- <b>operator</b>()
- (const_key_reference r_key,
- <a href=
-"#size_type55424436"><tt>size_type</tt></a> i) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the <span class="c1"><tt>i</tt></span>-th
- offset from the hash value of some key <span class=
- "c1"><tt>r_key</tt></span>.</p>
-
- <p><tt>size_type</tt> is the size type on which the
- functor operates.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_range_hashing.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_range_hashing.html
deleted file mode 100644
index 85051873c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_range_hashing.html
+++ /dev/null
@@ -1,172 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>sample_range_hashing Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>sample_range_hashing</tt> Interface</h1>
-
- <p>A sample range-hashing functor.</p>
-
- <p>This class serves to show the interface a range-hashing
- functor needs to support.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/hash_fn/sample_range_hashing.hpp"><tt>sample_range_hashing.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Public Types and
- Constants</a></h2>
-
- <h3><a name="link2" id="link2">General definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-size_t, e.g.
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Methods</a></h2>
-
- <h3><a name="link4" id="link4">Constructors, destructor, and
- related.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_range_hashing
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
-
- <p>Must be default constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_range_hashing
- (<b>const</b> sample_range_hashing &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
-
- <p>Must be copy constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- swap
- (sample_range_hashing &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
-
- <p>Must be swappable (if there is such a word).</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Protected Methods</a></h2>
-
- <h3><a name="link6" id="link6">Notification methods.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_resized
- (<a href="#size_type55424436"><tt>size_type</tt></a> size)
-</pre>
- </td>
-
- <td>
- <p>Notifies the policy object that the container's size
- has changed to <span class="c1"><tt>size</tt></span>.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Operators.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- <b>operator</b>()
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> hash) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Transforms the hash value <span class=
- "c1"><tt>hash</tt></span> into a ranged-hash value.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_hash_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_hash_fn.html
deleted file mode 100644
index 834f49650..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_hash_fn.html
+++ /dev/null
@@ -1,171 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>sample_ranged_hash_fn Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>sample_ranged_hash_fn</tt> Interface</h1>
-
- <p>A sample ranged-hash functor.</p>
-
- <p>This class serves to show the interface a ranged-hash
- functor needs to support.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/hash_fn/sample_ranged_hash_fn.hpp"><tt>sample_ranged_hash_fn.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Public Types and
- Constants</a></h2>
-
- <h3><a name="link2" id="link2">General definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-size_t, e.g.
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Methods</a></h2>
-
- <h3><a name="link4" id="link4">Constructors, destructor, and
- related.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_ranged_hash_fn
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
-
- <p>Must be default constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_ranged_hash_fn
- (<b>const</b> sample_ranged_hash_fn &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
-
- <p>Must be copy constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- swap
- (sample_ranged_hash_fn &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
-
- <p>Must be swappable (if there is such a word).</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Protected Methods</a></h2>
-
- <h3><a name="link6" id="link6">Notification methods.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_resized
- (<a href="#size_type55424436"><tt>size_type</tt></a> size)
-</pre>
- </td>
-
- <td>
- <p>Notifies the policy object that the container's size
- has changed to <span class="c1"><tt>size</tt></span>.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Operators.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- <b>operator</b>()
- (const_key_reference r_key) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Transforms <span class="c1"><tt>r_key</tt></span> into
- a position within the table.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_probe_fn.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_probe_fn.html
deleted file mode 100644
index ee1bc0664..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_ranged_probe_fn.html
+++ /dev/null
@@ -1,178 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>sample_ranged_probe_fn Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>sample_ranged_probe_fn</tt> Interface</h1>
-
- <p>A sample ranged-probe functor.</p>
-
- <p>This class serves to show the interface a ranged-probe
- functor needs to support.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/hash_fn/sample_ranged_probe_fn.hpp"><tt>sample_ranged_probe_fn.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Public Types and
- Constants</a></h2>
-
- <h3><a name="link2" id="link2">General definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-size_t, e.g.
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Methods</a></h2>
-
- <h3><a name="link4" id="link4">Constructors, destructor, and
- related.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_ranged_probe_fn
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
-
- <p>Must be default constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_ranged_probe_fn
- (<b>const</b> sample_ranged_probe_fn &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
-
- <p>Must be copy constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- swap
- (sample_ranged_probe_fn &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
-
- <p>Must be swappable (if there is such a word).</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Protected Methods</a></h2>
-
- <h3><a name="link6" id="link6">Notification methods.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_resized
- (<a href="#size_type55424436"><tt>size_type</tt></a> size)
-</pre>
- </td>
-
- <td>
- <p>Notifies the policy object that the container's size
- has changed to <span class="c1"><tt>size</tt></span>.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Operators.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- <b>operator</b>()
- (const_key_reference r_key,
- size_t hash,
- <a href=
-"#size_type55424436"><tt>size_type</tt></a> i) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Transforms the <tt><b>const</b></tt> key reference
- <span class="c1"><tt>r_key</tt></span> <span class=
- "c1"><tt>into the </tt></span><span class=
- "c1"><tt>i-th </tt></span>position within the table. This
- method <span class="c1"><tt>i</tt></span>s called for
- each collision within the probe sequence.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_policy.html
deleted file mode 100644
index 61ff09ba0..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_policy.html
+++ /dev/null
@@ -1,413 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>sample_resize_policy Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>sample_resize_policy</tt> Interface</h1>
-
- <p>A sample resize policy.</p>
-
- <p>This class serves to show the interface a resize policy
- needs to support.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/resize_policy/sample_resize_policy.hpp"><tt>sample_resize_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Public Types and
- Constants</a></h2>
-
- <h3><a name="link2" id="link2">General definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-size_t, e.g.
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Methods</a></h2>
-
- <h3><a name="link4" id="link4">Constructors, destructor, and
- related.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_resize_policy
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
-
- <p>Must be default constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_range_hashing
- (<b>const</b> sample_resize_policy &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
-
- <p>Must be copy constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- swap
- (sample_resize_policy &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
-
- <p>Must be swappable (if there is such a word).</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Protected Methods</a></h2>
-
- <h3><a name="link6" id="link6">Insert search
- notifications.</a></h3>
-
- <p>Notifications called during an insert operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Find search
- notifications.</a></h3>
-
- <p>Notifications called during a find operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link8" id="link8">Erase search
- notifications.</a></h3>
-
- <p>Notifications called during an insert operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link9" id="link9">Content change
- notifications.</a></h3>
-
- <p>Notifications called when the content of the table changes
- in a way that can affect the resize policy.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_inserted
- (<a href="#size_type55424436"><tt>size_type</tt></a> num_e)
-</pre>
- </td>
-
- <td>
- <p>Notifies an element was inserted.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erased
- (<a href="#size_type55424436"><tt>size_type</tt></a> num_e)
-</pre>
- </td>
-
- <td>
- <p>Notifies an element was erased.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_cleared
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was cleared.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link10" id="link10">Size change
- notifications.</a></h3>
-
- <p>Notifications called when the table changes size.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_resized
- (<a href="#size_type55424436"><tt>size_type</tt></a> new_size)
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was resized to <span class=
- "c1"><tt>new_size</tt></span>.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link11" id="link11">Queries.</a></h3>
-
- <p>Called to query whether/how to resize.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- is_resize_needed
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Queries whether a resize is needed.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#size_type55424436"><tt>size_type</tt></a>
- get_new_size
- (<a href="#size_type55424436"><tt>size_type</tt></a> size,
- <a href=
-"#size_type55424436"><tt>size_type</tt></a> num_used_e) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Queries what the new <span class=
- "c1"><tt>size</tt></span> should be.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_trigger.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_trigger.html
deleted file mode 100644
index 5c8173c8e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_resize_trigger.html
+++ /dev/null
@@ -1,462 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>sample_resize_trigger Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>sample_resize_trigger</tt> Interface</h1>
-
- <p>A sample resize trigger policy.</p>
-
- <p>This class serves to show the interface a trigger policy
- needs to support.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/resize_policy/sample_resize_trigger.hpp"><tt>
- sample_resize_trigger.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Public Types and
- Constants</a></h2>
-
- <h3><a name="link2" id="link2">General definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-size_t, e.g.
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Methods</a></h2>
-
- <h3><a name="link4" id="link4">Constructors, destructor, and
- related.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_resize_trigger
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
-
- <p>Must be default constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_range_hashing
- (<b>const</b> sample_resize_trigger &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
-
- <p>Must be copy constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- swap
- (sample_resize_trigger &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
-
- <p>Must be swappable (if there is such a word).</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Protected Methods</a></h2>
-
- <h3><a name="link6" id="link6">Insert search
- notifications.</a></h3>
-
- <p>Notifications called during an insert operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_insert_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Find search
- notifications.</a></h3>
-
- <p>Notifications called during a find operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_find_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link8" id="link8">Erase search
- notifications.</a></h3>
-
- <p>Notifications called during an insert operation.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_start
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search started.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_collision
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search encountered a collision.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erase_search_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies a search ended.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link9" id="link9">Content change
- notifications.</a></h3>
-
- <p>Notifications called when the content of the table changes
- in a way that can affect the resize policy.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_inserted
- (<a href="#size_type55424436"><tt>size_type</tt></a> num_entries)
-</pre>
- </td>
-
- <td>
- <p>Notifies an element was inserted. the total number of
- entries in the table is <span class=
- "c1"><tt>num_entries</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- notify_erased
- (<a href="#size_type55424436"><tt>size_type</tt></a> num_entries)
-</pre>
- </td>
-
- <td>
- <p>Notifies an element was erased.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_cleared
- ()
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was cleared.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link10" id="link10">Size change
- notifications.</a></h3>
-
- <p>Notifications called when the table changes size.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_resized
- (<a href="#size_type55424436"><tt>size_type</tt></a> new_size)
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was resized as a result of this
- object's signifying that a resize is needed.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- notify_externally_resized
- (<a href="#size_type55424436"><tt>size_type</tt></a> new_size)
-</pre>
- </td>
-
- <td>
- <p>Notifies the table was resized externally.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link11" id="link11">Queries.</a></h3>
-
- <p>Called to query whether/how to resize.</p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- is_resize_needed
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Queries whether a resize is needed.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- is_grow_needed
- (<a href="#size_type55424436"><tt>size_type</tt></a> size,
- <a href=
-"#size_type55424436"><tt>size_type</tt></a> num_entries) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Queries whether a grow is needed.</p>
-
- <p>This method is called only if this object indicated
- resize is needed. The actual <span class=
- "c1"><tt>size</tt></span> of the table is <span class=
- "c1"><tt>size</tt></span>, and the number of entries in
- it is <span class="c1"><tt>num_entries</tt></span>.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link12" id="link12">Private Methods</a></h2>
-
- <h3><a name="link13" id="link13">Overrides.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <b>void</b>
- do_resize
- (<a href="#size_type55424436"><tt>size_type</tt></a> new_size)
-</pre>
- </td>
-
- <td>
- <p>Resizes to <span class=
- "c1"><tt>new_size</tt></span>.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_size_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_size_policy.html
deleted file mode 100644
index ebb14d30b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_size_policy.html
+++ /dev/null
@@ -1,163 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>sample_size_policy Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>sample_size_policy</tt> Interface</h1>
-
- <p>A sample size policy.</p>
-
- <p>This class serves to show the interface a size policy needs
- to support.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/resize_policy/sample_size_policy.hpp"><tt>sample_size_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Public Types and
- Constants</a></h2>
-
- <h3><a name="link2" id="link2">General definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-size_t, e.g.
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Methods</a></h2>
-
- <h3><a name="link4" id="link4">Constructors, destructor, and
- related.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_size_policy
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
-
- <p>Must be default constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_range_hashing
- (<b>const</b> sample_size_policy &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
-
- <p>Must be copy constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- swap
- (sample_size_policy &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
-
- <p>Must be swappable (if there is such a word).</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Protected Methods</a></h2>
-
- <h3><a name="link6" id="link6">Size methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- get_nearest_larger_size
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> size) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Given a size <span class="c1"><tt>size</tt></span>,
- returns a size that is larger.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- get_nearest_smaller_size
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> size) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Given a size <span class="c1"><tt>size</tt></span>,
- returns a size that is smaller.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_tree_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_tree_node_update.html
deleted file mode 100644
index aefd67056..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_tree_node_update.html
+++ /dev/null
@@ -1,193 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>sample_tree_node_update Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>sample_tree_node_update</tt> Interface</h1>
-
- <p>A sample node updater.</p>
-
- <p>This class serves to show the interface a node update
- functor needs to support.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/tree_policy/sample_tree_node_update.hpp"><tt>
- sample_tree_node_update.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Const_Node_Iterator1933878761" id=
-"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Const node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Node_Iterator4206909839" id=
-"Node_Iterator4206909839"><b>class</b> Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Cmp_Fn294335" id="Cmp_Fn294335"><b>class</b> Cmp_Fn</a>
-</pre>
- </td>
-
- <td>
- <p>Comparison functor.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator</a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>-</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">Metadata definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_type2849297114" id=
-"metadata_type2849297114">metadata_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-size_t
-</pre>
- </td>
-
- <td>
- <p>Metadata type.</p>
-
- <p>This can be any type; size_t is merely an example.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link4" id="link4">Protected Methods</a></h2>
-
- <h3><a name="link5" id="link5">Conclassors, declassor, and
- related.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_tree_node_update
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
-
- <p>Must be default constructable.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link6" id="link6">Operators.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- <b>operator</b>()
- (node_iterator node_it,
- const_node_iterator end_nd_it) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Updates the rank of a node through a <span class=
- "c1"><tt>node_iterator</tt></span> <span class=
- "c1"><tt>node_it</tt></span>; <span class=
- "c1"><tt>end_nd_it</tt></span> is the end node
- iterator.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_e_access_traits.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_e_access_traits.html
deleted file mode 100644
index a46c91b1d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_e_access_traits.html
+++ /dev/null
@@ -1,231 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>sample_trie_e_access_traits Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>sample_trie_e_access_traits</tt> Interface</h1>
-
- <p>A sample trie element-access traits.</p>
-
- <p>This class serves to show the interface an element- access
- traits class needs to support.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/trie_policy/sample_trie_e_access_traits.hpp">
- <tt>sample_trie_e_access_traits.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Public Types and
- Constants</a></h2>
-
- <h3><a name="link2" id="link2">General definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-size_t, e.g.
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="key_type10393186" id="key_type10393186">key_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-std::string, e.g.
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_key_reference3185471705" id=
-"const_key_reference3185471705">const_key_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-const string &amp;, e.g.
-</pre>
- </td>
-
- <td>
- <p>Const key reference type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link3" id="link3">Element definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_iterator98626788" id=
-"const_iterator98626788">const_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-string::const_iterator, e.g.
-</pre>
- </td>
-
- <td>
- <p>Element <tt><b>const</b></tt> iterator type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="e_type393186" id="e_type393186">e_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-char, e.g.
-</pre>
- </td>
-
- <td>
- <p>Element type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="max_size10483336" id="max_size10483336">max_size</a>
-</pre>
- </td>
-
- <td>
- <pre>
-4, e.g.
-</pre>
- </td>
-
- <td>
- <p>Number of distinct elements.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link4" id="link4">Public Methods</a></h2>
-
- <h3><a name="link5" id="link5">Access methods.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>static</b> <a href=
-"#const_iterator98626788"><tt>const_iterator</tt></a>
- begin
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key)
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a> to
- the first element of <span class=
- "c1"><tt>r_key</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>static</b> <a href=
-"#const_iterator98626788"><tt>const_iterator</tt></a>
- end
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key)
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a> to
- the after-last element of <span class=
- "c1"><tt>r_key</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>static</b> <a href=
-"#size_type55424436"><tt>size_type</tt></a>
- e_pos
- (<a href="#e_type393186"><tt>e_type</tt></a> e)
-</pre>
- </td>
-
- <td>
- <p>Maps an <span class="c1"><tt>element</tt></span> to a
- position.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_node_update.html
deleted file mode 100644
index 61b6b407f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_trie_node_update.html
+++ /dev/null
@@ -1,194 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>sample_trie_node_update Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>sample_trie_node_update</tt> Interface</h1>
-
- <p>A sample node updater.</p>
-
- <p>This class serves to show the interface a node update
- functor needs to support.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/trie_policy/sample_trie_node_update.hpp"><tt>
- sample_trie_node_update.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Const_Node_Iterator1933878761" id=
-"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Const node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Node_Iterator4206909839" id=
-"Node_Iterator4206909839"><b>class</b> Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="E_Access_Traits686553840" id=
-"E_Access_Traits686553840"><b>class</b> E_Access_Traits</a>
-</pre>
- </td>
-
- <td>
- <p>Comparison functor.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator</a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>-</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">Metadata definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_type2849297114" id=
-"metadata_type2849297114">metadata_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-size_t
-</pre>
- </td>
-
- <td>
- <p>Metadata type.</p>
-
- <p>This can be any type; size_t is merely an example.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link4" id="link4">Protected Methods</a></h2>
-
- <h3><a name="link5" id="link5">Conclassors, declassor, and
- related.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_trie_node_update
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
-
- <p>Must be default constructable.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link6" id="link6">Operators.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- <b>operator</b>()
- (node_iterator node_it,
- const_node_iterator end_nd_it) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Updates the rank of a node through a <span class=
- "c1"><tt>node_iterator</tt></span> <span class=
- "c1"><tt>node_it</tt></span>; <span class=
- "c1"><tt>end_nd_it</tt></span> is the end node
- iterator.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_update_policy.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_update_policy.html
deleted file mode 100644
index 8a286c74c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/sample_update_policy.html
+++ /dev/null
@@ -1,178 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>sample_update_policy Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>sample_update_policy</tt> Interface</h1>
-
- <p>A sample list-update policy.</p>
-
- <p>This class serves to show the interface a list update
- functor needs to support.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/detail/list_update_policy/sample_update_policy.hpp"><tt>sample_update_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Public Methods</a></h2>
-
- <h3><a name="link2" id="link2">Constructors, destructor, and
- related.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_update_policy
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
-
- <p>Must be default constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- sample_update_policy
- (<b>const</b> sample_update_policy &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
-
- <p>Must be copy constructable.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- swap
- (sample_update_policy &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
-
- <p>Must be swappable (if there is such a word).</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Protected Types and
- Constants</a></h2>
-
- <h3><a name="link4" id="link4">Metadata definitions.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_type2849297114" id=
-"metadata_type2849297114">metadata_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-Some metadata type.
-</pre>
- </td>
-
- <td>
- <p>Metadata on which this functor operates.</p>
-
- <p>The <tt><b>class</b></tt> must declare the metadata
- type on which it operates; the list-update based
- containers will append to each node an object of this
- type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Protected Methods</a></h2>
-
- <h3><a name="link6" id="link6">Metadata operations.</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#metadata_type2849297114"><tt>metadata_type</tt></a>
- <b>operator</b>()
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Creates a metadata object.</p>
-
- <p>A list-update based container object will call this
- method to create a metadata type when a node is
- created.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>bool</b>
- <b>operator</b>()
- (metadata_reference r_data) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Decides whether a metadata object should be moved to
- the front of the list. A list-update based containers
- object will call this method to decide whether to move a
- node to the front of the list. The method should return
- <tt><b>true</b></tt> if the node should be moved to the
- front of the list.</p>
-
- <p><tt>metadata_reference</tt> is a reference to a
- <a href=
- "#metadata_type2849297114"><tt>metadata_type</tt></a>.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/simple_list.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/simple_list.png
deleted file mode 100644
index 9a05d3f5e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/simple_list.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/splay_tree_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/splay_tree_tag.html
deleted file mode 100644
index 3e6a64b1c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/splay_tree_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>splay_tree_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>splay_tree_tag</tt> Interface</h1>
-
- <p>Splay tree data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="tree_tag.html"><span class=
-"c2"><tt>tree_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/string_trie_e_access_traits.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/string_trie_e_access_traits.html
deleted file mode 100644
index 4ce9e864a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/string_trie_e_access_traits.html
+++ /dev/null
@@ -1,400 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>string_trie_e_access_traits Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>string_trie_e_access_traits</tt> Interface</h1>
-
- <p>Element access traits for string types.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/trie_policy.hpp"><tt>trie_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="String349403" id="String349403"><b>class</b> String </a>
-</pre>
- </td>
-
- <td>
- <p>String type.</p>
- </td>
-
- <td><tt>std::string</tt></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Min_E_Val40354618" id=
-"Min_E_Val40354618"><b>typename</b> </a><a href=
-"#String349403"><tt>String</tt></a>::value_type Min_E_Val
-</pre>
- </td>
-
- <td>
- <p>Minimal element.</p>
- </td>
-
- <td><tt>SCHAR_MIN</tt></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Max_E_Val39885868" id=
-"Max_E_Val39885868"><b>typename</b> </a><a href=
-"#String349403"><tt>String</tt></a>::value_type Max_E_Val
-</pre>
- </td>
-
- <td>
- <p>Maximal element.</p>
- </td>
-
- <td><tt>SCHAR_MAX</tt></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Reverse1686776" id=
-"Reverse1686776"><b>bool</b> Reverse </a>
-</pre>
- </td>
-
- <td>
- <p>Indicates whether reverse iteration should be
- used.</p>
- </td>
-
- <td><tt><b>false</b></tt></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator </a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>
- <pre>
-std::allocator&lt;<b>char</b>&gt;
-</pre>
- </td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#Allocator35940069"><tt>Allocator</tt></a>::size_type
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">Key-Type Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="key_type10393186" id="key_type10393186">key_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#String349403"><tt>String</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_key_reference3185471705" id=
-"const_key_reference3185471705">const_key_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#key_type10393186"><tt>key_type</tt></a>&gt;::other::const_reference
-</pre>
- </td>
-
- <td>
- <p>Const key reference type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link5" id="link5">Element-Type
- Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="reverse2186776" id="reverse2186776">reverse</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Reverse1686776"><tt>Reverse</tt></a>
-</pre>
- </td>
-
- <td>
- <p><a href="#Reverse1686776"><tt>Reverse</tt></a>
- iteration indicator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_iterator98626788" id=
-"const_iterator98626788">const_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> __gnu_pbds::detail::__conditional_type&lt;
- <a href="#Reverse1686776"><tt>Reverse</tt></a>,
- <b>typename</b> <a href=
-"#String349403"><tt>String</tt></a>::const_reverse_iterator,
- <b>typename</b> <a href=
-"#String349403"><tt>String</tt></a>::const_iterator&gt;::__type
-</pre>
- </td>
-
- <td>
- <p>Element <tt><b>const</b></tt> iterator type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="e_type393186" id="e_type393186">e_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> std::iterator_traits&lt;<a href=
-"#const_iterator98626788"><tt>const_iterator</tt></a>&gt;::value_type
-</pre>
- </td>
-
- <td>
- <p>Element type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="min_e_val52875418" id="min_e_val52875418">min_e_val</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Min_E_Val40354618"><tt>Min_E_Val</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Minimal element.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="max_e_val52406668" id="max_e_val52406668">max_e_val</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Max_E_Val39885868"><tt>Max_E_Val</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Maximal element.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="max_size10483336" id="max_size10483336">max_size</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#max_e_val52406668"><tt>max_e_val</tt></a> - <a href=
-"#min_e_val52875418"><tt>min_e_val</tt></a> + 1
-</pre>
- </td>
-
- <td>
- <p>Number of distinct elements.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link6" id="link6">Public Methods</a></h2>
-
- <h3><a name="link7" id="link7">Access Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>static</b> <a href=
-"#const_iterator98626788"><tt>const_iterator</tt></a>
- begin
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key)
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a> to
- the first element of <span class=
- "c1"><tt>r_key</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>static</b> <a href=
-"#const_iterator98626788"><tt>const_iterator</tt></a>
- end
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key)
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a> to
- the after-last element of <span class=
- "c1"><tt>r_key</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>static</b> <a href=
-"#size_type55424436"><tt>size_type</tt></a>
- e_pos
- (<a href="#e_type393186"><tt>e_type</tt></a> e)
-</pre>
- </td>
-
- <td>
- <p>Maps an <span class="c1"><tt>e</tt></span>element to a
- position.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tests.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tests.html
deleted file mode 100644
index ab5d54bb4..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tests.html
+++ /dev/null
@@ -1,24 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Tests</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Tests</h1>
-
- <p><a href="assoc_tests.html">Associative-Container Tests</a>
- describes tests for associative containers; <a href=
- "pq_tests.html">Priority-Queue Tests</a> describes tests for
- priority queues.</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_gcc.png
deleted file mode 100644
index 59247ec6a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_local.png
deleted file mode 100644
index d85980f30..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_msvc.png
deleted file mode 100644
index 227164568..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_hash_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_gcc.png
deleted file mode 100644
index 8b6c4f0f0..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_local.png
deleted file mode 100644
index b7fdc4746..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_msvc.png
deleted file mode 100644
index dc82a4e7e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/text_find_timing_test_tree_like_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/thin_heap_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/thin_heap_tag.html
deleted file mode 100644
index c44189664..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/thin_heap_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>thin_heap_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>thin_heap_tag</tt> Interface</h1>
-
- <p>Thin heap data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="priority_queue_tag.html"><span class=
-"c2"><tt>priority_queue_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree.html
deleted file mode 100644
index 3202a6e9f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree.html
+++ /dev/null
@@ -1,516 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>tree Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>tree</tt> Interface</h1>
-
- <p>A concrete basic tree-based associative container.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Key2501" id="Key2501"><b>typename</b> Key</a>
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a>
-</pre>
- </td>
-
- <td>
- <p>Mapped type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Cmp_Fn294335" id="Cmp_Fn294335"><b>class</b> Cmp_Fn </a>
-</pre>
- </td>
-
- <td>
- <p>Comparison functor.</p>
- </td>
-
- <td>
- <pre>
-std::less&lt;<a href="#Key2501"><tt>Key</tt></a>&gt;
-</pre>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Tag278938" id="Tag278938"><b>class</b> Tag </a>
-</pre>
- </td>
-
- <td>
- <p>Mapped-structure tag.</p>
- </td>
-
- <td><a href="rb_tree_tag.html"><span class=
- "c2"><tt>rb_tree_tag</tt></span></a></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Node_Update841554648" id=
-"Node_Update841554648"><b>template</b>&lt;
- <b>typename</b> Const_Node_Iterator,
- <b>typename</b> Node_Iterator,
- <b>class</b> Cmp_Fn_,
- <b>typename</b> Allocator_&gt;
-<b>class</b> Node_Update </a>
-</pre>
- </td>
-
- <td>
- <p>Node updater type.</p>
-
- <p><a href=
- "tree_based_containers.html#invariants">Design::Tree-Based
- Containers::Node Invariants</a> explains this
- concept.</p>
- </td>
-
- <td><a href="null_tree_node_update.html"><span class=
- "c2"><tt>null_tree_node_update</tt></span></a></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator </a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>
- <pre>
-std::allocator&lt;<b>char</b>&gt;
-</pre>
- </td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="basic_tree.html"><span class=
-"c2"><tt>basic_tree</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link3" id="link3">Public Types and
- Constants</a></h2>
-
- <h3><a name="link4" id="link4">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="cmp_fn394495" id="cmp_fn394495">cmp_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Cmp_Fn294335"><tt>Cmp_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Comparison functor type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link5" id="link5">Iterator Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_node_iterator4205924553" id=
-"const_node_iterator4205924553">const_node_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"tree_const_node_iterator.html"><span class=
-"c2"><tt>const_node_iterator</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>Const node iterator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="node_iterator3431975247" id=
-"node_iterator3431975247">node_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="tree_node_iterator.html"><span class=
-"c2"><tt>node_iterator</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>Node iterator.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link6" id="link6">Public Methods</a></h2>
-
- <h3><a name="link7" id="link7">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- tree
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- tree
- (<b>const</b> <a href=
-"#cmp_fn394495"><tt>cmp_fn</tt></a> &amp;r_cmp_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking some policy objects. <span class=
- "c1"><tt>r_cmp_fn</tt></span> will be copied by the
- <a href="#Cmp_Fn294335"><tt>Cmp_Fn</tt></a> object of the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- tree
- (It first_it,
- It last_it)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of
- value_types. The value_types between <span class=
- "c1"><tt>first_it</tt></span> and <span class=
- "c1"><tt>last_it</tt></span> will be inserted into the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- tree
- (It first_it,
- It last_it,
- <b>const</b> <a href=
-"#cmp_fn394495"><tt>cmp_fn</tt></a> &amp;r_cmp_fn)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of value_types
- and some policy objects The value_types between
- <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object. <span class=
- "c1"><tt>r_cmp_fn</tt></span> will be copied by the
- <a href="#cmp_fn394495"><tt>cmp_fn</tt></a> object of the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- tree
- (<b>const</b> <span class=
-"c2"><tt>tree</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b>
- ~tree
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<span class="c2"><tt>tree</tt></span> &amp;
- <b>operator</b>=
- (<b>const</b> <span class=
-"c2"><tt>tree</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Assignment operator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class=
-"c2"><tt>tree</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link8" id="link8">Policy Access Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#cmp_fn394495"><tt>cmp_fn</tt></a> &amp;
- get_cmp_fn
- ()
-</pre>
- </td>
-
- <td>
- <p>Access to the <a href=
- "#cmp_fn394495"><tt>cmp_fn</tt></a> object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>const</b> <a href="#cmp_fn394495"><tt>cmp_fn</tt></a> &amp;
- get_cmp_fn
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Const access to the <a href=
- "#cmp_fn394495"><tt>cmp_fn</tt></a> object.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link9" id="link9">Node-Iteration Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#node_iterator3431975247"><tt>node_iterator</tt></a>
- node_begin
- ()
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#node_iterator3431975247"><tt>node_iterator</tt></a>
- corresponding to the node at the root of the tree.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- node_begin
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- corresponding to the node at the root of the tree.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#node_iterator3431975247"><tt>node_iterator</tt></a>
- node_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#node_iterator3431975247"><tt>node_iterator</tt></a>
- corresponding to a node just after a leaf of the
- tree.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- node_end
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- corresponding to a node just after a leaf of the
- tree.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_based_containers.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_based_containers.html
deleted file mode 100644
index 63c7c7482..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_based_containers.html
+++ /dev/null
@@ -1,358 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Tree-Based Containers</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Tree Design</h1>
-
- <h2><a name="overview" id="overview">Overview</a></h2>
-
- <p>The tree-based container has the following declaration:</p>
- <pre>
-<b>template</b>&lt;
- <b>typename</b> Key,
- <b>typename</b> Mapped,
- <b>typename</b> Cmp_Fn = std::less&lt;Key&gt;,
- <b>typename</b> Tag = <a href="rb_tree_tag.html">rb_tree_tag</a>,
- <b>template</b>&lt;
- <b>typename</b> Const_Node_Iterator,
- <b>typename</b> Node_Iterator,
- <b>typename</b> Cmp_Fn_,
- <b>typename</b> Allocator_&gt;
- <b>class</b> Node_Update = <a href=
-"null_tree_node_update.html">null_tree_node_update</a>,
- <b>typename</b> Allocator = std::allocator&lt;<b>char</b>&gt; &gt;
-<b>class</b> <a href=
-"tree.html">tree</a>;
-</pre>
-
- <p>The parameters have the following meaning:</p>
-
- <ol>
- <li><tt>Key</tt> is the key type.</li>
-
- <li><tt>Mapped</tt> is the mapped-policy.</li>
-
- <li><tt>Cmp_Fn</tt> is a key comparison functor</li>
-
- <li><tt>Tag</tt> specifies which underlying data structure
- to use.</li>
-
- <li><tt>Node_Update</tt> is a policy for updating node
- invariants. This is described in <a href="#invariants">Node
- Invariants</a>.</li>
-
- <li><tt>Allocator</tt> is an allocator
- type.</li>
- </ol>
-
- <p>The <tt>Tag</tt> parameter specifies which underlying
- data structure to use. Instantiating it by <a href=
- "rb_tree_tag.html"><tt>rb_tree_tag</tt></a>, <a href=
- "splay_tree_tag.html"><tt>splay_tree_tag</tt></a>, or
- <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>,
- specifies an underlying red-black tree, splay tree, or
- ordered-vector tree, respectively; any other tag is illegal.
- Note that containers based on the former two contain more types
- and methods than the latter (<i>e.g.</i>,
- <tt>reverse_iterator</tt> and <tt>rbegin</tt>), and different
- exception and invalidation guarantees.</p>
-
- <h2><a name="invariants" id="invariants">Node
- Invariants</a></h2>
-
- <p>Consider the two trees in Figures <a href=
- "#node_invariants">Some node invariants</a> A and B. The first
- is a tree of floats; the second is a tree of pairs, each
- signifying a geometric line interval. Each element in a tree is refered to as a node of the tree. Of course, each of
- these trees can support the usual queries: the first can easily
- search for <tt>0.4</tt>; the second can easily search for
- <tt>std::make_pair(10, 41)</tt>.</p>
-
- <p>Each of these trees can efficiently support other queries.
- The first can efficiently determine that the 2rd key in the
- tree is <tt>0.3</tt>; the second can efficiently determine
- whether any of its intervals overlaps
- <tt>std::make_pair(29,42)</tt> (useful in geometric
- applications or distributed file systems with leases, for
- example). (See <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/tree_order_statistics.cc"><tt>tree_order_statistics.cc</tt></a>
- and <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/tree_intervals.cc"><tt>tree_intervals.cc</tt></a>
- for examples.) It should be noted that an <tt>std::set</tt> can
- only solve these types of problems with linear complexity.</p>
-
- <p>In order to do so, each tree stores some <i>metadata</i> in
- each node, and maintains node invariants <a href=
- "references.html#clrs2001">clrs2001</a>]. The first stores in
- each node the size of the sub-tree rooted at the node; the
- second stores at each node the maximal endpoint of the
- intervals at the sub-tree rooted at the node.</p>
-
- <h6 class="c1"><a name="node_invariants" id=
- "node_invariants"><img src="node_invariants.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Some node invariants.</h6>
-
- <p>Supporting such trees is difficult for a number of
- reasons:</p>
-
- <ol>
- <li>There must be a way to specify what a node's metadata
- should be (if any).</li>
-
- <li>Various operations can invalidate node invariants.
- <i>E.g.</i>, Figure <a href=
- "#node_invariant_invalidations">Invalidation of node
- invariants</a> shows how a right rotation, performed on A,
- results in B, with nodes <i>x</i> and <i>y</i> having
- corrupted invariants (the grayed nodes in C); Figure <a href=
- "#node_invariant_invalidations">Invalidation of node
- invariants</a> shows how an insert, performed on D, results
- in E, with nodes <i>x</i> and <i>y</i> having corrupted
- invariants (the grayed nodes in F). It is not feasible to
- know outside the tree the effect of an operation on the nodes
- of the tree.</li>
-
- <li>The search paths of standard associative containers are
- defined by comparisons between keys, and not through
- metadata.</li>
-
- <li>It is not feasible to know in advance which methods trees
- can support. Besides the usual <tt>find</tt> method, the
- first tree can support a <tt>find_by_order</tt> method, while
- the second can support an <tt>overlaps</tt> method.</li>
- </ol>
-
- <h6 class="c1"><a name="node_invariant_invalidations" id=
- "node_invariant_invalidations"><img src=
- "node_invariant_invalidations.png" alt="no image" /></a></h6>
-
- <h6 class="c1">Invalidation of node invariants.</h6>
-
- <p>These problems are solved by a combination of two means:
- node iterators, and template-template node updater
- parameters.</p>
-
- <h3><a name="node_it" id="node_it">Node Iterators</a></h3>
-
- <p>Each tree-based container defines two additional iterator
- types, <a href=
- "tree_const_node_iterator.html"><tt>const_node_iterator</tt></a>
- and <a href=
- "tree_node_iterator.html"><tt>node_iterator</tt></a>.
- These iterators allow descending from a node to one of its
- children. Node iterator allow search paths different than those
- determined by the comparison functor. <a href=
- "tree.html">tree</a>
- supports the methods:</p>
- <pre>
- <a href="tree_const_node_iterator.html"><tt>const_node_iterator</tt></a>
- node_begin() <b>const</b>;
-
- <a href="tree_node_iterator.html"><tt>node_iterator</tt></a>
- node_begin();
-
- <a href="tree_const_node_iterator.html"><tt>const_node_iterator</tt></a>
- node_end() <b>const</b>;
-
- <a href="tree_node_iterator.html"><tt>node_iterator</tt></a>
- node_end();
-</pre>
-
- <p>The first pairs return node iterators corresponding to the
- root node of the tree; the latter pair returns node iterators
- corresponding to a just-after-leaf node.</p>
-
- <h3><a name="node_up" id="node_up">Node Updater
- (Template-Template) Parameters</a></h3>
-
- <p>The tree-based containers are parametrized by a
- <tt>Node_Update</tt> template-template parameter. A tree-based
- container instantiates <tt>Node_Update</tt> to some
- <tt>node_update</tt> class, and publicly
- subclasses <tt>node_update</tt>. Figure
- <a href="#tree_node_update_cd">A tree and its update
- policy</a> shows this scheme, as well as some predefined
- policies (which are explained below).</p>
-
- <h6 class="c1"><a name="tree_node_update_cd" id=
- "tree_node_update_cd"><img src=
- "tree_node_update_policy_cd.png" alt="no image" /></a></h6>
-
- <h6 class="c1">A tree and its update policy.</h6>
-
- <p><tt>node_update</tt> (an instantiation of
- <tt>Node_Update</tt>) must define <tt>metadata_type</tt> as
- the type of metadata it requires. For order statistics,
- <i>e.g.</i>, <tt>metadata_type</tt> might be <tt>size_t</tt>.
- The tree defines within each node a <tt>metadata_type</tt>
- object.</p>
-
- <p><tt>node_update</tt> must also define the following method
- for restoring node invariants:</p>
- <pre>
- void
- operator()(<a href=
-"tree_node_iterator.html"><tt>node_iterator</tt></a> nd_it, <a href=
-"tree_const_node_iterator.html"><tt>const_node_iterator</tt></a> end_nd_it)
-</pre>
-
- <p>In this method, <tt>nd_it</tt> is a <a href=
- "tree_node_iterator.html"><tt>node_iterator</tt></a>
- corresponding to a node whose A) all descendants have valid
- invariants, and B) its own invariants might be violated;
- <tt>end_nd_it</tt> is a <a href=
- "tree_const_node_iterator.html"><tt>const_node_iterator</tt></a>
- corresponding to a just-after-leaf node. This method should
- correct the node invariants of the node pointed to by
- <tt>nd_it</tt>. For example, say node <i>x</i> in Figure
- <a href="#restoring_node_invariants">Restoring node
- invariants</a>-A has an invalid invariant, but its' children,
- <i>y</i> and <i>z</i> have valid invariants. After the
- invocation, all three nodes should have valid invariants, as in
- Figure <a href="#restoring_node_invariants">Restoring node
- invariants</a>-B.</p>
-
- <h6 class="c1"><a name="restoring_node_invariants" id=
- "restoring_node_invariants"><img src=
- "restoring_node_invariants.png" alt="no image" /></a></h6>
-
- <h6 class="c1">Invalidation of node invariants.</h6>
-
- <p>When a tree operation might invalidate some node invariant,
- it invokes this method in its <tt>node_update</tt> base to
- restore the invariant. For example, Figure <a href=
- "#update_seq_diagram">Insert update sequence diagram</a> shows
- an <tt>insert</tt> operation (point A); the tree performs some
- operations, and calls the update functor three times (points B,
- C, and D). (It is well known that any <tt>insert</tt>,
- <tt>erase</tt>, <tt>split</tt> or <tt>join</tt>, can restore
- all node invariants by a small number of node invariant updates
- [<a href="references.html#clrs2001">clrs2001</a>].)</p>
-
- <h6 class="c1"><a name="update_seq_diagram" id=
- "update_seq_diagram"><img src="update_seq_diagram.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Insert update sequence diagram.</h6>
-
- <p>To complete the description of the scheme, three questions
- need to be answered:</p>
-
- <ol>
- <li>How can a tree which supports order statistics define a
- method such as <tt>find_by_order</tt>?</li>
-
- <li>How can the node updater base access methods of the
- tree?</li>
-
- <li>How can the following cyclic dependency be resolved?
- <tt>node_update</tt> is a base class of the tree, yet it
- uses node iterators defined in the tree (its child).</li>
- </ol>
-
- <p>The first two questions are answered by the fact that
- <tt>node_update</tt> (an instantiation of
- <tt>Node_Update</tt>) is a <tt><b>public</b></tt> base class
- of the tree. Consequently:</p>
-
- <ol>
- <li>Any public methods of <tt>node_update</tt> are
- automatically methods of the tree [<a href=
- "references.html#alexandrescu01modern">alexandrescu01modern</a>].
- Thus an order-statistics node updater, <a href=
- "tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a>
- defines the <tt>find_by_order</tt> method; any tree
- instantiated by this policy consequently supports this method
- as well.</li>
-
- <li>In C++, if a base class declares a method as
- <tt><b>virtual</b></tt>, it is <tt><b>virtual</b></tt> in its
- subclasses. If <tt>node_update</tt> needs to access one of
- the tree's methods, say the member function <tt>end</tt>, it simply
- declares that method as <tt><b>virtual</b></tt>
- abstract.</li>
- </ol>
-
- <p>The cyclic dependency is solved through template-template
- parameters. <tt>Node_Update</tt> is parametrized by the tree's node iterators, its comparison
- functor, and its allocator type. Thus,
- instantiations of <tt>Node_Update</tt> have all information required.</p>
-
- <p class="c1"><tt>pb_ds</tt> assumes that constructing a metadata object and modifying it
- are exception free. Suppose that during some method, say
- <tt>insert</tt>, a metadata-related operation
- (<i>e.g.</i>, changing the value of a metadata) throws an
- exception. Ack! Rolling back the method is unusually complex.</p>
-
- <p>In <a href=
- "concepts.html#concepts_null_policies">Interface::Concepts::Null
- Policy Classes</a> a distinction was made between <i>redundant
- policies</i> and <i>null policies</i>. Node invariants show a
- case where null policies are required.</p>
-
- <p>Assume a regular tree is required, one which need not
- support order statistics or interval overlap queries.
- Seemingly, in this case a redundant policy - a policy which
- doesn't affect nodes' contents would suffice. This, would lead
- to the following drawbacks:</p>
-
- <ol>
- <li>Each node would carry a useless metadata object, wasting
- space.</li>
-
- <li>The tree cannot know if its <tt>Node_Update</tt> policy
- actually modifies a node's metadata (this is halting
- reducible). In Figure <a href=
- "#rationale_null_node_update">Useless update path</a> ,
- assume the shaded node is inserted. The tree would have to
- traverse the useless path shown to the root, applying
- redundant updates all the way.</li>
- </ol>
-
- <h6 class="c1"><a name="rationale_null_node_update" id=
- "rationale_null_node_update"><img src=
- "rationale_null_node_update.png" alt="no image" /></a></h6>
-
- <h6 class="c1">Useless update path.</h6>
-
- <p>A null policy class, <a href=
- "null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
- solves both these problems. The tree detects that node
- invariants are irrelevant, and defines all accordingly.</p>
-
- <h2><a name="add_methods" id="add_methods">Additional
- Methods</a></h2>
-
- <p>Tree-based containers support split and join methods.
- It is possible to split a tree so that it passes
- all nodes with keys larger than a given key to a different
- tree. These methods have the following advantages over the
- alternative of externally inserting to the destination
- tree and erasing from the source tree:</p>
-
- <ol>
- <li>These methods are efficient - red-black trees are split
- and joined in poly-logarithmic complexity; ordered-vector
- trees are split and joined at linear complexity. The
- alternatives have super-linear complexity.</li>
-
- <li>Aside from orders of growth, these operations perform
- few allocations and de-allocations. For red-black trees, allocations are not performed,
- and the methods are exception-free. </li>
- </ol>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_iterator.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_iterator.html
deleted file mode 100644
index ba09b5b4d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_iterator.html
+++ /dev/null
@@ -1,143 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>tree::node_iterator Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt><span class=
- "c2"><tt>tree</tt></span>::node_iterator</tt>
- Interface</h1>
-
- <p>Node iterator.</p>
-
- <p>This is an <quote>iterator to an iterator </quote> - it
- iterates over nodes, and de-referencing it returns one of the
- tree's iterators</p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href=
-"tree.html#const_node_iterator4205924553"><span class="c2"><tt>tree</tt></span>::const_node_iterator</a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Methods</a></h2>
-
- <h3><a name="link3" id="link3">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b>
- node_iterator
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">Access Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href=
-"container_base.html#iterator10418194"><span class=
-"c2"><tt>container_base</tt></span>::iterator</a>
- <b>operator</b>*
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Access.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link5" id="link5">Movement Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <span class="c2"><tt>node_iterator</tt></span>
- get_l_child
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the node iterator associated with the left
- node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <span class="c2"><tt>node_iterator</tt></span>
- get_r_child
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the node iterator associated with the right
- node.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_updator_policy_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_updator_policy_cd.png
deleted file mode 100644
index 5cae5781a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_node_updator_policy_cd.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_node_update.html
deleted file mode 100644
index f4345531f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_node_update.html
+++ /dev/null
@@ -1,678 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>tree_order_statistics_node_update Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>tree_order_statistics_node_update</tt> Interface</h1>
-
- <p>Functor updating ranks of entrees.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tree_policy.hpp"><tt>tree_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Const_Node_Iterator1933878761" id=
-"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Const node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Node_Iterator4206909839" id=
-"Node_Iterator4206909839"><b>class</b> Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Cmp_Fn294335" id="Cmp_Fn294335"><b>class</b> Cmp_Fn</a>
-</pre>
- </td>
-
- <td>
- <p>Comparison functor.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator</a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>-</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="cmp_fn394495" id="cmp_fn394495">cmp_fn</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Cmp_Fn294335"><tt>Cmp_Fn</tt></a>
-</pre>
- </td>
-
- <td>
- <p><a href="#Allocator35940069"><tt>Allocator</tt></a>
- type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="allocator48440069" id="allocator48440069">allocator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Allocator35940069"><tt>Allocator</tt></a>
-</pre>
- </td>
-
- <td>
- <p><a href="#Allocator35940069"><tt>Allocator</tt></a>
- type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::size_type
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link5" id="link5">Key-type Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="key_type10393186" id="key_type10393186">key_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-The instantiating container's key type.
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_key_reference3185471705" id=
-"const_key_reference3185471705">const_key_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-The instantiating container's const key reference type.
-</pre>
- </td>
-
- <td>
- <p>Const key reference.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link6" id="link6">Metadata-Type
- Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_type2849297114" id=
-"metadata_type2849297114">metadata_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#size_type55424436"><tt>size_type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Metadata type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Iterator Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_node_iterator4205924553" id=
-"const_node_iterator4205924553">const_node_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"#Const_Node_Iterator1933878761"><tt>Const_Node_Iterator</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Const node iterator type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="node_iterator3431975247" id=
-"node_iterator3431975247">node_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Node_Iterator4206909839"><tt>Node_Iterator</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Node iterator type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_iterator98626788" id=
-"const_iterator98626788">const_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>::value_type
-</pre>
- </td>
-
- <td>
- <p>Const iterator type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="iterator10418194" id="iterator10418194">iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#node_iterator3431975247"><tt>node_iterator</tt></a>::value_type
-</pre>
- </td>
-
- <td>
- <p>Iterator type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link8" id="link8">Public Methods</a></h2>
-
- <h3><a name="link9" id="link9">Find-Type Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href=
-"#const_iterator98626788"><tt>const_iterator</tt></a>
- find_by_order
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> order) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Finds an entry by order. Returns a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a> to
- the entry with the order <span class=
- "c1"><tt>order</tt></span>, or a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a> to
- the container object's end if <span class=
- "c1"><tt>order</tt></span> is at least the size of the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#iterator10418194"><tt>iterator</tt></a>
- find_by_order
- (<a href="#size_type55424436"><tt>size_type</tt></a> order)
-</pre>
- </td>
-
- <td>
- <p>Finds an entry by order. Returns an <a href=
- "#iterator10418194"><tt>iterator</tt></a> to the entry
- with the order <span class="c1"><tt>order</tt></span>, or
- an <a href="#iterator10418194"><tt>iterator</tt></a> to
- the container object's end if <span class=
- "c1"><tt>order</tt></span> is at least the size of the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- order_of_key
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the order of a key within a sequence. For
- example, if <span class="c1"><tt>r_key</tt></span> is the
- smallest key, this method will return 0; if <span class=
- "c1"><tt>r_key</tt></span> is a key between the smallest
- and next key, this method will return 1; if <span class=
- "c1"><tt>r_key</tt></span> is a key larger than the
- largest key, this method will return the size of r_c.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link10" id="link10">Protected Types and
- Constants</a></h2>
-
- <h3><a name="link11" id="link11">Value-type
- Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_reference495461441" id=
-"const_reference495461441">const_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-The instantiating container's const reference type.
-</pre>
- </td>
-
- <td>
- <p>Const reference to the container's value-type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_pointer878814947" id=
-"const_pointer878814947">const_pointer</a>
-</pre>
- </td>
-
- <td>
- <pre>
-The instantiating container's const pointer type.
-</pre>
- </td>
-
- <td>
- <p>Const pointer to the container's value-type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_metadata_reference1108857465" id=
-"const_metadata_reference1108857465">const_metadata_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#metadata_type2849297114"><tt>metadata_type</tt></a>&gt;::other::<a href="#const_reference495461441"><tt>const_reference</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Const metadata reference.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_reference583863863" id=
-"metadata_reference583863863">metadata_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#metadata_type2849297114"><tt>metadata_type</tt></a>&gt;::other::reference
-</pre>
- </td>
-
- <td>
- <p>Metadata reference.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link12" id="link12">Protected Methods</a></h2>
-
- <h3><a name="link13" id="link13">Operators</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- <b>operator</b>()
- (<a href=
-"#node_iterator3431975247"><tt>node_iterator</tt></a> node_it,
- <a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> end_nd_it) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Updates the rank of a node through a <a href=
- "#node_iterator3431975247"><tt>node_iterator</tt></a>
- <span class="c1"><tt>node_it</tt></span>; <span class=
- "c1"><tt>end_nd_it</tt></span> is the end node <a href=
- "#iterator10418194"><tt>iterator</tt></a>.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link14" id="link14">Constructors, destructor, and
- related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b>
- ~tree_order_statistics_node_update
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link15" id="link15">Private Methods</a></h2>
-
- <h3><a name="link16" id="link16">Overrides</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- node_begin
- () <b>const</b> = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- associated with the tree's root node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#node_iterator3431975247"><tt>node_iterator</tt></a>
- node_begin
- () = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#node_iterator3431975247"><tt>node_iterator</tt></a>
- associated with the tree's root node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- node_end
- () <b>const</b> = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- associated with a just-after leaf node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#node_iterator3431975247"><tt>node_iterator</tt></a>
- node_end
- () = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#node_iterator3431975247"><tt>node_iterator</tt></a>
- associated with a just-after leaf node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href="#cmp_fn394495"><tt>cmp_fn</tt></a> &amp;
- get_cmp_fn
- () = 0
-</pre>
- </td>
-
- <td>
- <p>Access to the <a href=
- "#cmp_fn394495"><tt>cmp_fn</tt></a> object.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test.html
deleted file mode 100644
index ef811613e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test.html
+++ /dev/null
@@ -1,118 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Tree Order Statistics Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Tree Order-Statistics Timing Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test creates a container, inserts random integers into
- the the container, and then checks the order-statistics of the
- container's values. (If the container is one of <tt>pb_ds</tt>
- 's trees, it does this with the <tt>order_of_key</tt> method of
- <a href="tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a>
- ; otherwise, it uses the <tt>find</tt> method and
- <tt>std::distance</tt> .) It measures the average time for such
- queries as a function of the number of values inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/tree_order_statistics_timing.cc"><tt>tree_order_statistics_timing_test</tt></a>
- 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the performance difference of policies based
- on node-invariant as opposed to a external functions. (see
- <a href="tree_based_containers.html#invariants">Design::Associative
- Containers::Tree-Based Containers::Node Invariants</a> .)</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and
- <a href="#NTL">NTL</a> show the results for the native and
- tree-based containers in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NTG_res_div">
-<div id="NTG_gcc">
-<div id="NTG_tree_order_statistics_timing_test">
-<div id="NTG_assoc">
-<div id="NTG_Native_and_tree-based_container_order-statistics_queries"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="tree_order_statistics_timing_test_gcc.png" alt="no image" /></a></h6>NTG: Native and tree-based container order-statistics queries - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_set-
-<tt>std::set</tt></li>
-<li>
-splay_tree_ost_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a>
-</li>
-<li>
-rb_tree_ost_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTM_res_div">
-<div id="NTM_msvc">
-<div id="NTM_tree_order_statistics_timing_test">
-<div id="NTM_assoc">
-<div id="NTM_Native_and_tree-based_container_order-statistics_queries"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="tree_order_statistics_timing_test_msvc.png" alt="no image" /></a></h6>NTM: Native and tree-based container order-statistics queries - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_set-
-<tt>std::set</tt></li>
-<li>
-splay_tree_ost_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a>
-</li>
-<li>
-rb_tree_ost_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTL_res_div">
-<div id="NTL_local">
-<div id="NTL_tree_order_statistics_timing_test">
-<div id="NTL_assoc">
-<div id="NTL_Native_and_tree-based_container_order-statistics_queries"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="tree_order_statistics_timing_test_local.png" alt="no image" /></a></h6>NTL: Native and tree-based container order-statistics queries - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>In this test, the native red-black tree can support
- order-statistics queries only externally, by performing a
- <tt>find</tt> (alternatively, <tt>lower_bound</tt> or
- <tt>upper_bound</tt> ) and then using <tt>std::distance</tt> .
- This is clearly linear, and it is not that surprising that the
- cost is high.</p>
-<p><tt>pb_ds</tt> 's tree-based containers use in this test the
- <tt>order_of_key</tt> method of <a href="tree_order_statistics_node_update.html"><tt>tree_order_statistics_node_update</tt></a>.
- This method has only linear complexity in the length of the
- root-node path. Unfortunately, the average path of a splay tree
- (<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> ) can
- be higher than logarithmic; the longest path of a red-black
- tree (<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> ) is
- logarithmic in the number of elements. Consequently, the splay
- tree has worse performance than the red-black tree.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_gcc.png
deleted file mode 100644
index bdb00d07a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_local.png
deleted file mode 100644
index 2b921743f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_msvc.png
deleted file mode 100644
index 76dcbee44..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_order_statistics_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_random_int_find_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_random_int_find_find_timing_test.html
deleted file mode 100644
index c34354f3e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_random_int_find_find_timing_test.html
+++ /dev/null
@@ -1,160 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Tree Text Find Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Tree-Based and Trie-Based Text <tt>find</tt> Find Timing
- Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with keys from an
- arbitrary text ([<a href="references.html#wickland96thirty">wickland96thirty</a>]) into
- a container, then performs a series of finds using
- <tt>find</tt>. It measures the average time for <tt>find</tt>
- as a function of the number of values inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/text_find_timing.cc"><tt>text_find_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- data structures.</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NTTG">NTTG</a>, <a href="#NTTM">NTTM</a>,
- and <a href="#NTTG">NTTL</a> show the results for the native,
- tree-based, and trie-based types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#local"><u>local</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NTTG_res_div">
-<div id="NTTG_gcc">
-<div id="NTTG_random_int_find_find_timing_test_tree">
-<div id="NTTG_assoc">
-<div id="NTTG_Native_456_tree-based_456_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTTG" id="NTTG"><img src="random_int_find_find_timing_test_tree_gcc.png" alt="no image" /></a></h6>NTTG: Native, tree-based, random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-splay_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-ov_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-n_map-
-<tt>std::map</tt></li>
-<li>
-rb_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-<div id="NTTM_res_div">
-<div id="NTTM_msvc">
-<div id="NTTM_random_int_find_find_timing_test_tree">
-<div id="NTTM_assoc">
-<div id="NTTM_Native_456_tree-based_456_random_int_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTTM" id="NTTM"><img src="random_int_find_find_timing_test_tree_msvc.png" alt="no image" /></a></h6>NTTM: Native, tree-based, random int find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-splay_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-ov_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-n_map-
-<tt>std::map</tt></li>
-<li>
-rb_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-<div id="NTTL_res_div">
-<div id="NTTL_local">
-<div id="NTTL_random_int_find_find_timing_test_tree">
-<div id="NTTL_assoc">
-<div id="NTTL_Native_456_tree-based_456_random_int_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTTL" id= "NTTL"><img src="random_int_find_find_timing_test_tree_local.png" alt="no image" /></a></h6>NTTL: Native, tree-based, random int find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>For this setting, a splay tree (<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>)
- does not do well. This is possibly due to two
- reasons:</p>
-<ol>
-<li>A splay tree is not guaranteed to be balanced
- [<a href="references.html#motwani95random">motwani95random</a>].
- If a splay tree contains <i>n</i> nodes, its
- average root-leaf path can be <i>m &gt;&gt;
- log(n)</i>.</li>
-<li>Assume a specific root-leaf search path has
- length <i>m</i>, and the search-target node has
- distance <i>m'</i> from the root. A red-black
- tree will require <i>m + 1</i> comparisons to
- find the required node; a splay tree will require
- <i>2 m'</i> comparisons. A splay tree,
- consequently, can perform many more comparisons
- than a red-black tree.</li>
-</ol>
-<p>An ordered-vector tree (<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>),
- a red-black tree (<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>rb_tree_tag</tt></a>),
- and the native red-black tree all share
- approximately the same performance.</p>
-<p>An ordered-vector tree is slightly slower than
- red-black trees, since it requires, in order to
- find a key, more math operations than they do.
- Conversely, an ordered-vector tree requires far
- lower space than the others. ([<a href="references.html#austern00noset">austern00noset</a>],
- however, seems to have an implementation that is
- also faster than a red-black tree).</p>
-<p>A PATRICIA trie (<a href="trie.html"><tt>trie</tt></a>
- with <tt>Tag =</tt> <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a>)
- has good look-up performance, due to its large
- fan-out in this case. In this setting, a PATRICIA
- trie has lookup performance comparable to a hash
- table (see <a href="hash_text_find_find_timing_test.html">Hash-Based
- Text <tt>find</tt> Find Timing Test</a>), but it is
- order preserving. This is not that surprising,
- since a large fan-out PATRICIA trie works like a
- hash table with collisions resolved by a sub-trie.
- A large fan-out PATRICIA trie does not do well on
- modifications (see <a href="tree_text_insert_timing_test.html">Tree-Based and
- Trie-Based Text Insert Timing Test</a>). It is
- possibly beneficial to semi-static settings,
- therefore.</p>
-<p><a href="assoc_performance_tests.html#tree_like_based_types">
- Observations::Tree-Like-Based Container Types</a>
- summarizes some observations on tree-based and
- trie-based containers.</p>
-</div>
-</div>
-</div>
-</div>
-</div>
-</div>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test.html
deleted file mode 100644
index 9164984d1..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test.html
+++ /dev/null
@@ -1,143 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Tree Split Join Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Tree Split-Join Timing Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test a container, inserts into a number of values,
- splits the container at the median, and joins the two
- containers. (If the containers are one of <tt>pb_ds</tt> 's
- trees, it splits and joins with the <tt>split</tt> and
- <tt>join</tt> method; otherwise, it uses the <tt>erase</tt> and
- <tt>insert</tt> methods.) It measures the time for splitting
- and joining the containers as a function of the number of
- values inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/tree_split_join_timing.cc"><tt>tree_split_join_timing_test</tt></a>
- 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the performance difference of <tt>join</tt>
- as opposed to a sequence of <tt>insert</tt> operations; by
- implication, this test checks the most efficient way to erase a
- sub-sequence from a tree-like-based container, since this can
- always be performed by a small sequence of splits and joins
- (see <a href="motivation.html#assoc_split_join_methods">Motivation::Associative
- Containers::Slightly Different Methods::Methods Related to
- Split and Join</a> and <a href="tree_based_containers.html#add_methods">Design::Associative
- Containers::Tree-Based Containers::Additional Methods</a>
- .)</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and
- <a href="#NTL">NTL</a> show the results for the native and
- tree-based containers in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NTG_res_div">
-<div id="NTG_gcc">
-<div id="NTG_tree_split_join_timing_test">
-<div id="NTG_assoc">
-<div id="NTG_Native_and_tree-based_container_splits_and_joins"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="tree_split_join_timing_test_gcc.png" alt="no image" /></a></h6>NTG: Native and tree-based container splits and joins - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_set-
-<tt>std::set</tt></li>
-<li>
-splay_tree_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-rb_tree_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-ov_tree_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTM_res_div">
-<div id="NTM_msvc">
-<div id="NTM_tree_split_join_timing_test">
-<div id="NTM_assoc">
-<div id="NTM_Native_and_tree-based_container_splits_and_joins"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="tree_split_join_timing_test_msvc.png" alt="no image" /></a></h6>NTM: Native and tree-based container splits and joins - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_set-
-<tt>std::set</tt></li>
-<li>
-splay_tree_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-rb_tree_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-ov_tree_set-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTL_res_div">
-<div id="NTL_local">
-<div id="NTL_tree_split_join_timing_test">
-<div id="NTL_assoc">
-<div id="NTL_Native_and_tree-based_container_splits_and_joins"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="tree_split_join_timing_test_local.png" alt="no image" /></a></h6>NTL: Native and tree-based container splits and joins - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>In this test, the native red-black trees must be split and
- joined externally, through a sequence of <tt>erase</tt> and
- <tt>insert</tt> operations. This is clearly super-linear, and
- it is not that surprising that the cost is high.</p>
-<p><tt>pb_ds</tt> 's tree-based containers use in this test the
- <tt>split</tt> and <tt>join</tt> methods, which have lower
- complexity: the <tt>join</tt> method of a splay tree ( <a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> ) is
- quadratic in the length of the longest root-leaf path, and
- linear in the total number of elements; the <tt>join</tt>
- method of a red-black tree ( <a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a> ) or an
- ordered-vector tree ( <a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> ) is linear
- in the number of elements.</p>
-<p>Asides from orders of growth, <tt>pb_ds</tt> 's trees access
- their allocator very little in these operations, and some of
- them do not access it at all. This leads to lower constants in
- their complexity, and, for some containers, to exception-free
- splits and joins (which can be determined via <a href="assoc_container_traits.html"><tt>container_traits</tt></a>).</p>
-<p>It is important to note that <tt>split</tt> and
- <tt>join</tt> are not esoteric methods - they are the most
- efficient means of erasing a contiguous range of values from a
- tree based container.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_gcc.png
deleted file mode 100644
index 88867eca6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_local.png
deleted file mode 100644
index 131d24a1a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_msvc.png
deleted file mode 100644
index 37ed1b2e7..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_split_join_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_tag.html
deleted file mode 100644
index d7265ac18..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>tree_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>tree_tag</tt> Interface</h1>
-
- <p>Basic tree data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="basic_tree_tag.html"><span class=
-"c2"><tt>basic_tree_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_find_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_find_find_timing_test.html
deleted file mode 100644
index fbfdfeffa..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_find_find_timing_test.html
+++ /dev/null
@@ -1,162 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Tree Text Find Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Tree-Based and Trie-Based Text <tt>find</tt> Find Timing
- Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with keys from an
- arbitrary text ([<a href="references.html#wickland96thirty">wickland96thirty</a>]) into
- a container, then performs a series of finds using
- <tt>find</tt>. It measures the average time for <tt>find</tt>
- as a function of the number of values inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/text_find_timing.cc"><tt>text_find_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- data structures.</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NTTG">NTTG</a>, <a href="#NTTM">NTTM</a>,
- and <a href="#NTTG">NTTL</a> show the results for the native,
- tree-based, and trie-based types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#local"><u>local</u></a>, and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NTTG_res_div">
-<div id="NTTG_gcc">
-<div id="NTTG_text_find_timing_test_tree_like">
-<div id="NTTG_assoc">
-<div id="NTTG_Native_456_tree-based_456_and_trie-based_456_text_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTTG" id="NTTG"><img src="text_find_timing_test_tree_like_gcc.png" alt="no image" /></a></h6>NTTG: Native, tree-based, and trie-based, text find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-splay_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-ov_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-rb_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-n_map-
-<tt>std::map</tt></li>
-<li>
-pat_trie_map-
-<a href="trie.html"><tt>trie</tt></a>
- with <tt>Tag</tt> = <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_trie_node_update.html"><tt>null_trie_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTTM_res_div">
-<div id="NTTM_msvc">
-<div id="NTTM_text_find_timing_test_tree_like">
-<div id="NTTM_assoc">
-<div id="NTTM_Native_456_tree-based_456_and_trie-based_456_text_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTTM" id="NTTM"><img src="text_find_timing_test_tree_like_msvc.png" alt="no image" /></a></h6>NTTM: Native, tree-based, and trie-based, text find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-splay_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-ov_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-rb_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-n_map-
-<tt>std::map</tt></li>
-<li>
-pat_trie_map-
-<a href="trie.html"><tt>trie</tt></a>
- with <tt>Tag</tt> = <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_trie_node_update.html"><tt>null_trie_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTTL_res_div">
-<div id="NTTL_local">
-<div id="NTTL_text_find_timing_test_tree_like">
-<div id="NTTL_assoc">
-<div id="NTTL_Native_456_tree-based_456_and_trie-based_456_text_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTTL" id= "NTTL"><img src="text_find_timing_test_tree_like_local.png" alt="no image" /></a></h6>NTTL: Native, tree-based, and trie-based, text find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>For this setting, a splay tree (<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>) does
- not do well. This is possibly due to two reasons:</p>
-<ol>
-<li>A splay tree is not guaranteed to be balanced [<a href="references.html#motwani95random">motwani95random</a>]. If a
- splay tree contains <i>n</i> nodes, its average root-leaf
- path can be <i>m &gt;&gt; log(n)</i>.</li>
-<li>Assume a specific root-leaf search path has length
- <i>m</i>, and the search-target node has distance <i>m'</i>
- from the root. A red-black tree will require <i>m + 1</i>
- comparisons to find the required node; a splay tree will
- require <i>2 m'</i> comparisons. A splay tree, consequently,
- can perform many more comparisons than a red-black tree.</li>
-</ol>
-<p>An ordered-vector tree (<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>), a red-black
- tree (<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>rb_tree_tag</tt></a>), and the
- native red-black tree all share approximately the same
- performance.</p>
-<p>An ordered-vector tree is slightly slower than red-black
- trees, since it requires, in order to find a key, more math
- operations than they do. Conversely, an ordered-vector tree
- requires far lower space than the others. ([<a href="references.html#austern00noset">austern00noset</a>], however,
- seems to have an implementation that is also faster than a
- red-black tree).</p>
-<p>A PATRICIA trie (<a href="trie.html"><tt>trie</tt></a>
- with <tt>Tag =</tt> <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a>) has good
- look-up performance, due to its large fan-out in this case. In
- this setting, a PATRICIA trie has look-up performance comparable
- to a hash table (see <a href="hash_text_find_find_timing_test.html">Hash-Based Text
- <tt>find</tt> Find Timing Test</a>), but it is order
- preserving. This is not that surprising, since a large-fan-out
- PATRICIA trie works like a hash table with collisions resolved
- by a sub-trie. A large-fan-out PATRICIA trie does not do well on
- modifications (see <a href="tree_text_insert_timing_test.html">Tree-Based and Trie-Based
- Text Insert Timing Test</a>). It is possibly beneficial to
- semi-static settings, therefore.</p>
-<p><a href="assoc_performance_tests.html#tree_like_based_types">Observations::Tree-Like-Based
- Container Types</a> summarizes some observations on tree-based
- and trie-based containers.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test.html
deleted file mode 100644
index a5815fb2e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test.html
+++ /dev/null
@@ -1,226 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Tree Text Insert Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Tree-Based and Trie-Based Text Insert Timing Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with keys from an
- arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into
- a container using <tt>insert</tt> . It measures the average
- time for <tt>insert</tt> as a function of the number of values
- inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/tree_text_insert_timing.cc"><tt>tree_text_insert_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- data structures.</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NNTG">NNTG</a>, <a href="#NVTG">NVTG</a>,
- and <a href="#NPTG">NPTG</a> show the results for the native
- tree and <tt>pb_ds</tt>'s node-based trees, the native tree and
- <tt>pb_ds</tt>'s vector-based trees, and the native tree
- and<tt>pb_ds</tt>'s PATRICIA-trie, respectively, in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>; Figures
- <a href="#NNTM">NNTM</a>, <a href="#NVTM">NVTM</a>, and
- <a href="#NPTM">NPTM</a> show the same in <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a>; Figures
- <a href="#NNTL">NNTL</a>, <a href="#NVTL">NVTL</a>, and
- <a href="#NPTL">NPTL</a> show the same in <a href="assoc_performance_tests.html#local"><u>local</u></a>.</p>
-<div id="NNTG_res_div">
-<div id="NNTG_gcc">
-<div id="NNTG_tree_text_insert_timing_test_node_tree">
-<div id="NNTG_assoc">
-<div id="NNTG_Native_tree_and_node-based_trees_text_insert_timing_test_using__tt_insert_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NNTG" id="NNTG"><img src="tree_text_insert_timing_test_node_tree_gcc.png" alt="no image" /></a></h6>NNTG: Native tree and node-based trees text insert timing test using <tt>insert</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-splay_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-n_map-
-<tt>std::map</tt></li>
-<li>
-rb_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NVTG_res_div">
-<div id="NVTG_gcc">
-<div id="NVTG_tree_text_insert_timing_test_vector_tree">
-<div id="NVTG_assoc">
-<div id="NVTG_Native_tree_and_vector-based_tree_text_insert_timing_test_using__tt_insert_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NVTG" id="NVTG"><img src="tree_text_insert_timing_test_vector_tree_gcc.png" alt="no image" /></a></h6>NVTG: Native tree and vector-based tree text insert timing test using <tt>insert</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-ov_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-n_map-
-<tt>std::map</tt></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPTG_res_div">
-<div id="NPTG_gcc">
-<div id="NPTG_tree_text_insert_timing_test_pat_trie">
-<div id="NPTG_assoc">
-<div id="NPTG_Native_tree_and_PATRICIA_trie_text_insert_timing_test_using__tt_insert_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPTG" id="NPTG"><img src="tree_text_insert_timing_test_pat_trie_gcc.png" alt="no image" /></a></h6>NPTG: Native tree and PATRICIA trie text insert timing test using <tt>insert</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-n_map-
-<tt>std::map</tt></li>
-<li>
-pat_trie_map-
-<a href="trie.html"><tt>trie</tt></a>
- with <tt>Tag</tt> = <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_trie_node_update.html"><tt>null_trie_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NNTM_res_div">
-<div id="NNTM_msvc">
-<div id="NNTM_tree_text_insert_timing_test_node_tree">
-<div id="NNTM_assoc">
-<div id="NNTM_Native_tree_and_node-based_trees_text_insert_timing_test_using__tt_insert_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NNTM" id="NNTM"><img src="tree_text_insert_timing_test_node_tree_msvc.png" alt="no image" /></a></h6>NNTM: Native tree and node-based trees text insert timing test using <tt>insert</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-splay_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-n_map-
-<tt>std::map</tt></li>
-<li>
-rb_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NVTM_res_div">
-<div id="NVTM_msvc">
-<div id="NVTM_tree_text_insert_timing_test_vector_tree">
-<div id="NVTM_assoc">
-<div id="NVTM_Native_tree_and_vector-based_tree_text_insert_timing_test_using__tt_insert_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NVTM" id="NVTM"><img src="tree_text_insert_timing_test_vector_tree_msvc.png" alt="no image" /></a></h6>NVTM: Native tree and vector-based tree text insert timing test using <tt>insert</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-ov_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-n_map-
-<tt>std::map</tt></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPTM_res_div">
-<div id="NPTM_msvc">
-<div id="NPTM_tree_text_insert_timing_test_pat_trie">
-<div id="NPTM_assoc">
-<div id="NPTM_Native_tree_and_PATRICIA_trie_text_insert_timing_test_using__tt_insert_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPTM" id="NPTM"><img src="tree_text_insert_timing_test_pat_trie_msvc.png" alt="no image" /></a></h6>NPTM: Native tree and PATRICIA trie text insert timing test using <tt>insert</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-pat_trie_map-
-<a href="trie.html"><tt>trie</tt></a>
- with <tt>Tag</tt> = <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_trie_node_update.html"><tt>null_trie_node_update</tt></a>
-</li>
-<li>
-n_map-
-<tt>std::map</tt></li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NNTL_res_div">
-<div id="NNTL_local">
-<div id="NNTL_tree_text_insert_timing_test_node_tree">
-<div id="NNTL_assoc">
-<div id="NNTL_Native_tree_and_node-based_trees_text_insert_timing_test_using__tt_insert_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NNTL" id= "NNTL"><img src="tree_text_insert_timing_test_node_tree_local.png" alt="no image" /></a></h6>NNTL: Native tree and node-based trees text insert timing test using <tt>insert</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NVTL_res_div">
-<div id="NVTL_local">
-<div id="NVTL_tree_text_insert_timing_test_vector_tree">
-<div id="NVTL_assoc">
-<div id="NVTL_Native_tree_and_vector-based_tree_text_insert_timing_test_using__tt_insert_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NVTL" id= "NVTL"><img src="tree_text_insert_timing_test_vector_tree_local.png" alt="no image" /></a></h6>NVTL: Native tree and vector-based tree text insert timing test using <tt>insert</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NPTL_res_div">
-<div id="NPTL_local">
-<div id="NPTL_tree_text_insert_timing_test_pat_trie">
-<div id="NPTL_assoc">
-<div id="NPTL_Native_tree_and_PATRICIA_trie_text_insert_timing_test_using__tt_insert_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NPTL" id= "NPTL"><img src="tree_text_insert_timing_test_pat_trie_local.png" alt="no image" /></a></h6>NPTL: Native tree and PATRICIA trie text insert timing test using <tt>insert</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>Observing Figure <a href="#NNTG">NNTG</a> , for this
- setting, a splay tree, ( <a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> ) does
- not do well. This was covered in <a href="tree_text_find_find_timing_test.html">Tree-Based and
- Trie-Based Text <tt>find</tt> Find Timing Test</a> . The two
- red-black trees perform better.</p>
-<p>Observing Figure <a href="#NVTG">NVTG</a>, an ordered-vector
- tree ( <a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>) performs
- abysmally. Inserting into this type of tree has linear
- complexity [ <a href="references.html#austern00noset">austern00noset</a>].</p>
-<p>Observing Figure <a href="#NPTG">NPTG</a> , A PATRICIA trie
- ( <a href="trie.html"><tt>trie</tt></a>
- with <tt>Tag =</tt> <a href="pat_trie_tag.html"><tt>pat_trie_tag</tt></a> ) has
- abysmal performance, as well. This is not that surprising,
- since a large-fan-out PATRICIA trie works like a hash table with
- collisions resolved by a sub-trie. Each time a collision is
- encountered, a new "hash-table" is built A large fan-out
- PATRICIA trie, however, doe does well in look-ups (see <a href="tree_text_find_find_timing_test.html">Tree-Based and
- Trie-Based Text <tt>find</tt> Find Timing Test</a> ). It is
- possibly beneficial to semi-static settings, therefore.</p>
-<p><a href="assoc_performance_tests.html#tree_like_based_types">Observations::Tree-Like-Based
- Container Types</a> summarizes some observations on tree-based
- and trie-based containers.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_gcc.png
deleted file mode 100644
index 22d8f6fc2..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_local.png
deleted file mode 100644
index bb100084b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_msvc.png
deleted file mode 100644
index 18b219851..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_node_tree_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_gcc.png
deleted file mode 100644
index 5fe063e63..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_local.png
deleted file mode 100644
index 228de1442..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_msvc.png
deleted file mode 100644
index 9f13db0c0..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_pat_trie_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_gcc.png
deleted file mode 100644
index dd85dcd7c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_local.png
deleted file mode 100644
index cecb8a107..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_msvc.png
deleted file mode 100644
index 8c0731391..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_insert_timing_test_vector_tree_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_find_timing_test.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_find_timing_test.html
deleted file mode 100644
index c577a56db..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_find_timing_test.html
+++ /dev/null
@@ -1,126 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
-<meta name="generator" content="HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-<title>Tree Text Locality of Reference Find Timing Test</title>
-<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
-</head>
-<body>
-<div id="page">
-<h1>Tree-Based Locality-of-Reference Text <tt>find</tt> Find
- Timing Test</h1>
-<h2><a name="description" id="description">Description</a></h2>
-<p>This test inserts a number of values with keys from an
- arbitrary text ([ <a href="references.html#wickland96thirty">wickland96thirty</a> ]) into
- a container, then performs a series of finds using
- <tt>find</tt> . It is different than <a href="tree_text_find_find_timing_test.html">Tree-Based and
- Trie-Based Text <tt>find</tt> Find Timing Test</a> in the
- sequence of finds it performs: this test performs multiple
- <tt>find</tt> s on the same key before moving on to the next
- key. It measures the average time for <tt>find</tt> as a
- function of the number of values inserted.</p>
-<p>(The test was executed with <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/performance/ext/pb_ds/tree_text_lor_find_timing.cc"><tt>tree_text_lor_find_timing_test</tt></a>
- thirty_years_among_the_dead_preproc.txt 200 200 2100)</p>
-<h2><a name="purpose" id="purpose">Purpose</a></h2>
-<p>The test checks the effect of different underlying
- data structures in a locality-of-reference setting.</p>
-<h2><a name="results" id="results">Results</a></h2>
-<p>Figures <a href="#NTG">NTG</a>, <a href="#NTM">NTM</a>, and
- <a href="#NTL">NTL</a> show the results for the native and
- <tt>pb_ds</tt> tree-based types in <a href="assoc_performance_tests.html#gcc"><u>g++</u></a>, <a href="assoc_performance_tests.html#msvc"><u>msvc++</u></a> and
- <a href="assoc_performance_tests.html#local"><u>local</u></a>,
- respectively.</p>
-<div id="NTG_res_div">
-<div id="NTG_gcc">
-<div id="NTG_tree_text_lor_find_timing_test">
-<div id="NTG_assoc">
-<div id="NTG_Native_and_tree-based_locality-of-reference_text_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTG" id="NTG"><img src="tree_text_lor_find_timing_test_gcc.png" alt="no image" /></a></h6>NTG: Native and tree-based locality-of-reference text find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#gcc">g++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-ov_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-rb_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-n_map-
-<tt>std::map</tt></li>
-<li>
-splay_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTM_res_div">
-<div id="NTM_msvc">
-<div id="NTM_tree_text_lor_find_timing_test">
-<div id="NTM_assoc">
-<div id="NTM_Native_and_tree-based_locality-of-reference_text_find_timing_test_using__tt_find_455tt_"><div style="border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTM" id="NTM"><img src="tree_text_lor_find_timing_test_msvc.png" alt="no image" /></a></h6>NTM: Native and tree-based locality-of-reference text find timing test using <tt>find</tt> - <a href="assoc_performance_tests.html#msvc">msvc++</a><p>In the above figure, the names in the legends have the following meaning:</p>
-<ol>
-<li>
-ov_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-rb_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="rb_tree_tag.html"><tt>rb_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-<li>
-n_map-
-<tt>std::map</tt></li>
-<li>
-splay_tree_map-
-<a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag</tt> = <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a>
-, and <tt>Node_Update</tt> = <a href="null_tree_node_update.html"><tt>null_tree_node_update</tt></a>
-</li>
-</ol>
-</div><div style="width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<div id="NTL_res_div">
-<div id="NTL_local">
-<div id="NTL_tree_text_lor_find_timing_test">
-<div id="NTL_assoc">
-<div id="NTL_Native_and_tree-based_locality-of-reference_text_find_timing_test_using__tt_find_455tt_"><div style = "border-style: dotted; border-width: 1px; border-color: lightgray"><h6 class="c1"><a name="NTL" id= "NTL"><img src="tree_text_lor_find_timing_test_local.png" alt="no image" /></a></h6>NTL: Native and tree-based locality-of-reference text find timing test using <tt>find</tt> - <a href = "assoc_performance_tests.html#local">local</a></div><div style = "width: 100%; height: 20px"></div></div>
-</div>
-</div>
-</div>
-</div>
-<h2><a name="observations" id="observations">Observations</a></h2>
-<p>For this setting, an ordered-vector tree ( <a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="ov_tree_tag.html"><tt>ov_tree_tag</tt></a> ), a
- red-black tree ( <a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>rb_tree_tag</tt></a> ), and the
- native red-black tree all share approximately the same
- performance.</p>
-<p>A splay tree ( <a href="tree.html"><tt>tree</tt></a>
- with <tt>Tag =</tt> <a href="splay_tree_tag.html"><tt>splay_tree_tag</tt></a> ) does
- much better, since each (successful) find "bubbles" the
- corresponding node to the root of the tree.</p>
-<p><a href="assoc_performance_tests.html#tree_like_based_types">Observations::Tree-Like-Based
- Container Types</a> summarizes some observations on tree-based
- and trie-based containers.</p>
-</div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_gcc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_gcc.png
deleted file mode 100644
index cf5174d99..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_gcc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_local.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_local.png
deleted file mode 100644
index 26f71510f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_local.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_msvc.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_msvc.png
deleted file mode 100644
index 583a027f3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tree_text_lor_find_timing_test_msvc.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie.html
deleted file mode 100644
index 32a2ab1b5..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie.html
+++ /dev/null
@@ -1,489 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>trie Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>trie</tt> Interface</h1>
-
- <p>A concrete basic trie-based associative container.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/assoc_container.hpp"><tt>assoc_container.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Key2501" id="Key2501"><b>typename</b> Key</a>
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Mapped318655" id="Mapped318655"><b>typename</b> Mapped</a>
-</pre>
- </td>
-
- <td>
- <p>Mapped type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="E_Access_Traits686553840" id=
-"E_Access_Traits686553840"><b>class</b> E_Access_Traits </a>
-</pre>
- </td>
-
- <td>
- <p>Element-access traits.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Tag278938" id="Tag278938"><b>class</b> Tag </a>
-</pre>
- </td>
-
- <td>
- <p>Data-structure tag.</p>
- </td>
-
- <td><a href="pat_trie_tag.html"><span class=
- "c2"><tt>pat_trie_tag</tt></span></a></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Node_Update841554648" id=
-"Node_Update841554648"><b>template</b>&lt;
- <b>typename</b> Const_Node_Iterator,
- <b>typename</b> Node_Iterator,
- <b>class</b> E_Access_Traits_,
- <b>typename</b> Allocator_&gt;
-<b>class</b> Node_Update </a>
-</pre>
- </td>
-
- <td>
- <p>Node updater type.</p>
-
- <p><a href=
- "tree_based_containers.html#invariants">Design::Tree-Based
- Containers::Node Invariants</a> explains this
- concept.</p>
- </td>
-
- <td><a href="null_trie_node_update.html"><span class=
- "c2"><tt>null_trie_node_update</tt></span></a></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator </a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>
- <pre>
-std::allocator&lt;<b>char</b>&gt;
-</pre>
- </td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="e_access_traits1948190928" id=
-"e_access_traits1948190928">e_access_traits</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#E_Access_Traits686553840"><tt>E_Access_Traits</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Element access traits type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">Iterator Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_node_iterator4205924553" id=
-"const_node_iterator4205924553">const_node_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"trie_const_node_iterator.html"><span class=
-"c2"><tt>const_node_iterator</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>Const node iterator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="node_iterator3431975247" id=
-"node_iterator3431975247">node_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="trie_node_iterator.html"><span class=
-"c2"><tt>node_iterator</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>Node iterator.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Public Methods</a></h2>
-
- <h3><a name="link6" id="link6">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
- trie
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- trie
- (<b>const</b> <a href=
-"#E_Access_Traits686553840"><tt>E_Access_Traits</tt></a> &amp;r_e_access_traits)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking some policy objects. <span class=
- "c1"><tt>r_e_access_traits</tt></span> will be copied by
- the <a href=
- "#E_Access_Traits686553840"><tt>E_Access_Traits</tt></a>
- object of the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- trie
- (It first_it,
- It last_it)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of
- value_types. The value_types between <span class=
- "c1"><tt>first_it</tt></span> and <span class=
- "c1"><tt>last_it</tt></span> will be inserted into the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>template</b>&lt;
- <b>class</b> It&gt;
- trie
- (It first_it,
- It last_it,
- <b>const</b> <a href=
-"#E_Access_Traits686553840"><tt>E_Access_Traits</tt></a> &amp;r_e_access_traits)
-</pre>
- </td>
-
- <td>
- <p>Constructor taking iterators to a range of value_types
- and some policy objects. The value_types between
- <span class="c1"><tt>first_it</tt></span> and
- <span class="c1"><tt>last_it</tt></span> will be inserted
- into the container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
- trie
- (<b>const</b> <span class=
-"c2"><tt>trie</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Copy constructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b>
- ~trie
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<span class="c2"><tt>trie</tt></span> &amp;
- <b>operator</b>=
- (<b>const</b> <span class=
-"c2"><tt>trie</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Assignment operator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>void</b>
- swap
- (<span class=
-"c2"><tt>trie</tt></span> &amp;other)
-</pre>
- </td>
-
- <td>
- <p>Swaps content.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Policy Access Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href=
-"#e_access_traits1948190928"><tt>e_access_traits</tt></a> &amp;
- get_e_access_traits
- ()
-</pre>
- </td>
-
- <td>
- <p>Access to the comb_hash_fn object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href=
-"#e_access_traits1948190928"><tt>e_access_traits</tt></a> &amp;
- get_e_access_traits
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Const access to the comb_hash_fn object.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link8" id="link8">Node-Iteration Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#node_iterator3431975247"><tt>node_iterator</tt></a>
- node_begin
- ()
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#node_iterator3431975247"><tt>node_iterator</tt></a>
- corresponding to the node at the root of the trie.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- node_begin
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- corresponding to the node at the root of the trie.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="#node_iterator3431975247"><tt>node_iterator</tt></a>
- node_end
- ()
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#node_iterator3431975247"><tt>node_iterator</tt></a>
- corresponding to a node just after a leaf of the
- trie.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- node_end
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a <a href=
- "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- corresponding to a node just after a leaf of the
- trie.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_based_containers.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_based_containers.html
deleted file mode 100644
index 72bdd0697..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_based_containers.html
+++ /dev/null
@@ -1,241 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Trie-Based Containers</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Trie Design</h1>
-
- <h2><a name="overview" id="overview">Overview</a></h2>
-
- <p>The trie-based container has the following declaration:</p>
- <pre>
-<b>template</b>&lt;
- <b>typename</b> Key,
- <b>typename</b> Mapped,
- <b>typename</b> Cmp_Fn = std::less&lt;Key&gt;,
- <b>typename</b> Tag = <a href="pat_trie_tag.html">pat_trie_tag</a>,
- <b>template</b>&lt;
- <b>typename</b> Const_Node_Iterator,
- <b>typename</b> Node_Iterator,
- <b>typename</b> E_Access_Traits_,
- <b>typename</b> Allocator_&gt;
- <b>class</b> Node_Update = <a href=
-"null_trie_node_update.html">null_trie_node_update</a>,
- <b>typename</b> Allocator = std::allocator&lt;<b>char</b>&gt; &gt;
-<b>class</b> <a href=
-"trie.html">trie</a>;
-</pre>
-
- <p>The parameters have the following meaning:</p>
-
- <ol>
- <li><tt>Key</tt> is the key type.</li>
-
- <li><tt>Mapped</tt> is the mapped-policy, and is explained in
- <a href="tutorial.html#assoc_ms">Tutorial::Associative
- Containers::Associative Containers Others than Maps</a>.</li>
-
- <li><tt>E_Access_Traits</tt> is described in <a href=
- "#e_access_traits">Element-Access Traits</a>.</li>
-
- <li><tt>Tag</tt> specifies which underlying data structure
- to use, and is described shortly.</li>
-
- <li><tt>Node_Update</tt> is a policy for updating node
- invariants. This is described in <a href="#invariants">Node
- Invariants</a>.</li>
-
- <li><tt>Allocator</tt> is an allocator
- type.</li>
- </ol>
-
- <p>The <tt>Tag</tt> parameter specifies which underlying
- data structure to use. Instantiating it by <a href=
- "pat_trie_tag.html">pat_trie_tag</a>, specifies an
- underlying PATRICIA trie (explained shortly); any other tag is
- currently illegal.</p>
- <hr />
-
- <p>Following is a description of a (PATRICIA) trie
- (<tt>pb_ds</tt> follows specifically [<a href=
- "references.html#okasaki98mereable">okasaki98mereable</a>] and
- [<a href=
- "references.html#filliatre2000ptset">filliatre2000ptset</a>]).</p>
-
- <p>A (PATRICIA) trie is similar to a tree, but with the
- following differences:</p>
-
- <ol>
- <li>It explicitly views keys as a sequence of elements.
- <i>E.g.</i>, a trie can view a string as a sequence of
- characters; a trie can view a number as a sequence of
- bits.</li>
-
- <li>It is not (necessarily) binary. Each node has fan-out <i>n
- + 1</i>, where <i>n</i> is the number of distinct
- elements.</li>
-
- <li>It stores values only at leaf nodes.</li>
-
- <li>Internal nodes have the properties that A) each has at
- least two children, and B) each shares the same prefix with
- any of its descendant.</li>
- </ol>
-
- <p><a href="#e_access_traits">Element-Access Traits</a> shows
- an example of such a trie.</p>
-
- <p>A (PATRICIA) trie has some useful properties:</p>
-
- <ol>
- <li>It can be configured to use large node fan-out, giving it
- very efficient find performance (albeit at insertion
- complexity and size).</li>
-
- <li>It works well for common-prefix keys.</li>
-
- <li>It can support efficiently queries such as which keys
- match a certain prefix. This is sometimes useful in
- file systems and routers.</li>
- </ol>
-
- <p>(We would like to thank Matt Austern for the suggestion to
- include tries.)</p>
-
- <h2><a name="e_access_traits" id=
- "e_access_traits">Element-Access Traits</a></h2>
-
- <p>A trie inherently views its keys as sequences of elements.
- For example, a trie can view a string as a sequence of
- characters. A trie needs to map each of <i>n</i> elements to a
- number in <i>{0, n - 1}</i>. For example, a trie can map a
- character <tt>c</tt> to
- <tt>static_cast&lt;size_t&gt;(c)</tt>.</p>
-
- <p>Seemingly, then, a trie can assume that its keys support
- (const) iterators, and that the <tt>value_type</tt> of this
- iterator can be cast to a <tt>size_t</tt>. There are several
- reasons, though, to decouple the mechanism by which the trie
- accesses its keys' elements from the trie:</p>
-
- <ol>
- <li>In some cases, the numerical value of an element is
- inappropriate. Consider a trie storing DNA strings. It is
- logical to use a trie with a fan-out of <i>5 = 1 + |{'A', 'C',
- 'G', 'T'}|</i>. This requires mapping 'T' to 3, though.</li>
-
- <li>In some cases the keys' iterators are different than what
- is needed. For example, a trie can be used to search for
- common <u>suffixes</u>, by using strings'
- <tt>reverse_iterator</tt>. As another example, a trie mapping
- UNICODE strings would have a huge fan-out if each node would
- branch on a UNICODE character; instead, one can define an
- iterator iterating over 8-bit (or less) groups.</li>
- </ol>
-
- <p><a href=
- "trie.html">trie</a> is,
- consequently, parametrized by <tt>E_Access_Traits</tt> -
- traits which instruct how to access sequences' elements.
- <a href=
- "string_trie_e_access_traits.html"><tt>string_trie_e_access_traits</tt></a>
- is a traits class for strings. Each such traits define some
- types, <i>e.g.</i>,</p>
- <pre>
-<b>typename</b> E_Access_Traits::const_iterator
-</pre>
-
- <p>is a const iterator iterating over a key's elements. The
- traits class must also define methods for obtaining an iterator
- to the first and last element of a key.</p>
-
- <p>Figure <a href="#pat_trie">A PATRICIA trie</a> shows a
- (PATRICIA) trie resulting from inserting the words: "I wish
- that I could ever see a poem lovely as a trie" (which,
- unfortunately, does not rhyme).</p>
-
- <p>The leaf nodes contain values; each internal node contains
- two <tt><b>typename</b> E_Access_Traits::const_iterator</tt>
- objects, indicating the maximal common prefix of all keys in
- the sub-tree. For example, the shaded internal node roots a
- sub-tree with leafs "a" and "as". The maximal common prefix is
- "a". The internal node contains, consequently, to const
- iterators, one pointing to <tt>'a'</tt>, and the other to
- <tt>'s'</tt>.</p>
-
- <h6 class="c1"><a name="pat_trie" id="pat_trie"><img src=
- "pat_trie.png" alt="no image" /></a></h6>
-
- <h6 class="c1">A PATRICIA trie.</h6>
-
- <h2><a name="invariants" id="invariants">Node
- Invariants</a></h2>
-
- <p>Trie-based containers support node invariants, as do
- tree-based containers (see <a href=
- "tree_based_containers.html#invariants">Tree-Based
- Containers::Node Invariants</a>). There are two minor
- differences, though, which, unfortunately, thwart sharing them
- sharing the same node-updating policies:</p>
-
- <ol>
- <li>A trie's <tt>Node_Update</tt> template-template
- parameter is parametrized by <tt>E_Access_Traits</tt>, while
- a tree's <tt>Node_Update</tt> template-template parameter is
- parametrized by <tt>Cmp_Fn</tt>.</li>
-
- <li>Tree-based containers store values in all nodes, while
- trie-based containers (at least in this implementation) store
- values in leafs.</li>
- </ol>
-
- <p>Figure <a href="#trie_node_update_cd">A trie and its update
- policy</a> shows the scheme, as well as some predefined
- policies (which are explained below).</p>
-
- <h6 class="c1"><a name="trie_node_update_cd" id=
- "trie_node_update_cd"><img src=
- "trie_node_update_policy_cd.png" alt="no image" /></a></h6>
-
- <h6 class="c1">A trie and its update policy.</h6>
-
- <p><tt>pb_ds</tt> offers the following pre-defined trie node
- updating policies:</p>
-
- <ol>
- <li><a href=
- "trie_order_statistics_node_update.html"><tt>trie_order_statistics_node_update</tt></a>
- supports order statistics.</li>
-
- <li><a href=
- "trie_prefix_search_node_update.html"><tt>trie_prefix_search_node_update</tt></a>
- supports searching for ranges that match a given prefix. See
- <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/trie_prefix_search.cc"><tt>trie_prefix_search.cc</tt></a>.</li>
-
- <li><a href=
- "null_trie_node_update.html"><tt>null_trie_node_update</tt></a>
- is the null node updater.</li>
- </ol>
-
- <h2><a name="add_methods" id="add_methods">Additional
- Methods</a></h2>
-
- <p>Trie-based containers support split and join methods; the
- rationale is equal to that of tree-based containers supporting
- these methods (see <a href=
- "tree_based_containers.html#add_methods">Tree-Based
- Containers::Additional Methods</a>).</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_const_node_iterator.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_const_node_iterator.html
deleted file mode 100644
index 0869a7c2f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_const_node_iterator.html
+++ /dev/null
@@ -1,478 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>trie::const_node_iterator
- Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt><span class=
- "c2"><tt>trie</tt></span>::const_node_iterator</tt>
- Interface</h1>
-
- <p>Const node iterator.</p>
-
- <p>This is an "iterator to an iterator" - it iterates over
- nodes, and de-referencing it returns one of the tree's const
- iterators</p>
-
- <h2><a name="link1" id="link1">Public Types and
- Constants</a></h2>
-
- <h3><a name="link2" id="link2">General Container
- Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="container_base.html#size_type55424436"><span class=
-"c2"><tt>container_base</tt></span>::size_type</a>
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link3" id="link3">Iterator Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="iterator_category2821876439" id=
-"iterator_category2821876439">iterator_category</a>
-</pre>
- </td>
-
- <td>
- <pre>
-trivial_iterator_tag
-</pre>
- </td>
-
- <td>
- <p>Category.</p>
-
- <p>This tag identifies that the iterator has none of the
- STL's iterators' movement abilities.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="difference_type868028452" id=
-"difference_type868028452">difference_type</a>
-</pre>
- </td>
-
- <td>
- <pre class="c2">
-void
-</pre>
- </td>
-
- <td>
- <p>Difference type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">Value-Type Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="value_type279018186" id=
-"value_type279018186">value_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"container_base.html#const_iterator98626788"><span class="c2"><tt>container_base</tt></span>::const_iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Iterator's value type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="reference54418471" id="reference54418471">reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#value_type279018186"><tt>value_type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Iterator's reference type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_reference495461441" id=
-"const_reference495461441">const_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#value_type279018186"><tt>value_type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Iterator's const <a href=
- "#reference54418471"><tt>reference</tt></a> type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="e_access_traits1948190928" id=
-"e_access_traits1948190928">e_access_traits</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"trie.html#e_access_traits1948190928"><span class="c2"><tt>trie</tt></span>::e_access_traits</a>
-</pre>
- </td>
-
- <td>
- <p>Element access traits.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_e_iterator2450008044" id=
-"const_e_iterator2450008044">const_e_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#e_access_traits1948190928"><tt>e_access_traits</tt></a>::const_iterator
-</pre>
- </td>
-
- <td>
- <p>A key's element const iterator.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link5" id="link5">Metadata Definitions</a></h3>
-
- <p>These are only defined if <a href=
- "basic_tree.html#Node_Update841554648"><span class="c2">
- <tt>basic_tree</tt></span>::Node_Update</a>
- is not <a href="null_trie_node_update.html"><span class=
- "c2"><tt>null_trie_node_update</tt></span></a></p>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_type2849297114" id=
-"metadata_type2849297114">metadata_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<tt><b>typename</b></tt> <a href=
-"basic_tree.html#Node_Update841554648"><span class="c2"><tt>basic_tree</tt></span>::Node_Update</a><tt>::metadata_type</tt>
-</pre>
- </td>
-
- <td>
- <p>Metadata type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_metadata_reference1108857465" id=
-"const_metadata_reference1108857465">const_metadata_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> Allocator::<b>template</b> rebind&lt;
- <a href=
-"#metadata_type2849297114"><tt>metadata_type</tt></a>&gt;::other::<a href="#const_reference495461441"><tt>const_reference</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Const metadata <a href=
- "#reference54418471"><tt>reference</tt></a> type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link6" id="link6">Public Methods</a></h2>
-
- <h3><a name="link7" id="link7">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b>
- const_node_iterator
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link8" id="link8">Access Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> std::pair&lt;
- <a href=
-"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a>,
- <a href=
-"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a>&gt;
- valid_prefix
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Subtree valid prefix.</p>
-
- <p>Returns the common prefix range of all nodes in this
- node's subtree.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href=
-"#const_reference495461441"><tt>const_reference</tt></a>
- <b>operator</b>*
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Const access; returns the const iterator associated
- with the current leaf.</p>
-
- <p>Should be called only for leaf nodes.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link9" id="link9">Metadata Access Methods</a></h3>
-
- <p>These are only defined if <a href=
- "basic_tree.html#Node_Update841554648"><span class="c2">
- <tt>basic_tree</tt></span>::Node_Update</a>
- is not <a href="null_trie_node_update.html"><span class=
- "c2"><tt>null_trie_node_update</tt></span></a></p>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href=
-"#const_metadata_reference1108857465"><tt>const_metadata_reference</tt></a>
- get_metadata
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Metadata access.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link10" id="link10">Movement Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- num_children
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the number of children in the corresponding
- node.</p>
-
- <p>If the number of children is 0, then the corresponding
- node is a leaf; otherwise, it is not a leaf.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<span class="c2"><tt>const_node_iterator</tt></span>
- get_child
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> i) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a const node iterator to the corresponding
- node's <span class="c1"><tt>i</tt></span>-th child.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link11" id="link11">Comparison Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- <b>operator</b>==
- (<b>const</b> <span class=
-"c2"><tt>const_node_iterator</tt></span> &amp;other) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Compares content to a different iterator object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>bool</b>
- <b>operator</b>!=
- (<b>const</b> <span class=
-"c2"><tt>const_node_iterator</tt></span> &amp;other) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Compares content (negatively) to a different iterator
- object.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_iterator.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_iterator.html
deleted file mode 100644
index 55029c4cb..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_iterator.html
+++ /dev/null
@@ -1,235 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>trie::node_iterator Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt><span class=
- "c2"><tt>trie</tt></span>::node_iterator</tt>
- Interface</h1>
-
- <p>Node iterator.</p>
-
- <p>This is an "iterator to an iterator" - it iterates over
- nodes, and de-referencing it returns one of the tree's
- iterators</p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href=
-"trie.html#const_node_iterator4205924553"><span class="c2"><tt>trie</tt></span>::const_node_iterator</a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">General Container
- Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"trie.html#const_node_iterator4205924553"><span class="c2"><tt>trie</tt></span>::const_node_iterator</a>::size_type
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">Value-Type Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="value_type279018186" id=
-"value_type279018186">value_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="container_base.html#iterator10418194"><span class=
-"c2"><tt>container_base</tt></span>::iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Iterator's value type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="reference54418471" id="reference54418471">reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#value_type279018186"><tt>value_type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Iterator's reference type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_reference495461441" id=
-"const_reference495461441">const_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#value_type279018186"><tt>value_type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Iterator's const <a href=
- "#reference54418471"><tt>reference</tt></a> type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link5" id="link5">Public Methods</a></h2>
-
- <h3><a name="link6" id="link6">Constructors, Destructor, and
- Related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b>
- pat_trie_node_it_
- ()
-</pre>
- </td>
-
- <td>
- <p>Default constructor.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Access Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#reference54418471"><tt>reference</tt></a>
- <b>operator</b>*
- () <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Access; returns the iterator associated with the
- current leaf.</p>
-
- <p>Should be called only for leaf nodes.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link8" id="link8">Movement Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<span class="c2"><tt>node_iterator</tt></span>
- get_child
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> i) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns a node iterator to the corresponding node's
- <span class="c1"><tt>i</tt></span>-th child.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_updator_policy_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_updator_policy_cd.png
deleted file mode 100644
index 4376929ec..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_node_updator_policy_cd.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_order_statistics_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_order_statistics_node_update.html
deleted file mode 100644
index 66aab26d7..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_order_statistics_node_update.html
+++ /dev/null
@@ -1,770 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>trie_order_statistics_node_update Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>trie_order_statistics_node_update</tt> Interface</h1>
-
- <p>Functor updating ranks of entrees.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/trie_policy.hpp"><tt>trie_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Const_Node_Iterator1933878761" id=
-"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Const node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Node_Iterator4206909839" id=
-"Node_Iterator4206909839"><b>class</b> Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="E_Access_Traits686553840" id=
-"E_Access_Traits686553840"><b>class</b> E_Access_Traits</a>
-</pre>
- </td>
-
- <td>
- <p>Comparison functor.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator</a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>-</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="e_access_traits1948190928" id=
-"e_access_traits1948190928">e_access_traits</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#E_Access_Traits686553840"><tt>E_Access_Traits</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Element access traits.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_e_iterator2450008044" id=
-"const_e_iterator2450008044">const_e_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#e_access_traits1948190928"><tt>e_access_traits</tt></a>::const_iterator
-</pre>
- </td>
-
- <td>
- <p>Const element iterator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="allocator48440069" id="allocator48440069">allocator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Allocator35940069"><tt>Allocator</tt></a>
-</pre>
- </td>
-
- <td>
- <p><a href="#Allocator35940069"><tt>Allocator</tt></a>
- type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::size_type
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link5" id="link5">Key-Type Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="key_type10393186" id="key_type10393186">key_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-The instantiating container's key type.
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_key_reference3185471705" id=
-"const_key_reference3185471705">const_key_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-The instantiating container's const key reference type.
-</pre>
- </td>
-
- <td>
- <p>Const key reference.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link6" id="link6">Metadata-Type
- Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_type2849297114" id=
-"metadata_type2849297114">metadata_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#size_type55424436"><tt>size_type</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Metadata type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Iterator Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_node_iterator4205924553" id=
-"const_node_iterator4205924553">const_node_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"#Const_Node_Iterator1933878761"><tt>Const_Node_Iterator</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Const node iterator type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="node_iterator3431975247" id=
-"node_iterator3431975247">node_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Node_Iterator4206909839"><tt>Node_Iterator</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Node iterator type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_iterator98626788" id=
-"const_iterator98626788">const_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>::value_type
-</pre>
- </td>
-
- <td>
- <p>Const iterator type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="iterator10418194" id="iterator10418194">iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#node_iterator3431975247"><tt>node_iterator</tt></a>::value_type
-</pre>
- </td>
-
- <td>
- <p>Iterator type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link8" id="link8">Public Methods</a></h2>
-
- <h3><a name="link9" id="link9">Find-Type Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href=
-"#const_iterator98626788"><tt>const_iterator</tt></a>
- find_by_order
- (<a href=
-"#size_type55424436"><tt>size_type</tt></a> order) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Finds an entry by order. Returns a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a> to
- the entry with the order <span class=
- "c1"><tt>order</tt></span>, or a <a href=
- "#const_iterator98626788"><tt>const_iterator</tt></a> to
- the container object's end if <span class=
- "c1"><tt>order</tt></span> is at least the size of the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#iterator10418194"><tt>iterator</tt></a>
- find_by_order
- (<a href="#size_type55424436"><tt>size_type</tt></a> order)
-</pre>
- </td>
-
- <td>
- <p>Finds an entry by order. Returns an <a href=
- "#iterator10418194"><tt>iterator</tt></a> to the entry
- with the order <span class="c1"><tt>order</tt></span>, or
- an <a href="#iterator10418194"><tt>iterator</tt></a> to
- the container object's end if <span class=
- "c1"><tt>order</tt></span> is at least the size of the
- container object.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- order_of_key
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the order of a key within a sequence. For
- example, if <span class="c1"><tt>r_key</tt></span> is the
- smallest key, this method will return 0; if <span class=
- "c1"><tt>r_key</tt></span> is a key between the smallest
- and next key, this method will return 1; if <span class=
- "c1"><tt>r_key</tt></span> is a key larger than the
- largest key, this method will return the size of r_c.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <a href="#size_type55424436"><tt>size_type</tt></a>
- order_of_prefix
- (<a href=
-"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a> b,
- <a href=
-"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a> e) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Returns the order of a prefix within a sequence. For
- <span class="c1"><tt>e</tt></span>example, if [b,
- <span class="c1"><tt>e</tt></span>] is the smallest
- prefix, this method will return 0; if r_key is a key
- <span class="c1"><tt>b</tt></span>between the smallest and
- next key, this method will return 1; if r_key is a key
- larger than the largest key, this method will return the
- size of r_c.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link10" id="link10">Protected Types and
- Constants</a></h2>
-
- <h3><a name="link11" id="link11">Value-Type
- Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_reference495461441" id=
-"const_reference495461441">const_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-The instantiating container's const reference type.
-</pre>
- </td>
-
- <td>
- <p>Const reference to the container's value-type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_pointer878814947" id=
-"const_pointer878814947">const_pointer</a>
-</pre>
- </td>
-
- <td>
- <pre>
-The instantiating container's const pointer type.
-</pre>
- </td>
-
- <td>
- <p>Const pointer to the container's value-type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_metadata_reference1108857465" id=
-"const_metadata_reference1108857465">const_metadata_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#metadata_type2849297114"><tt>metadata_type</tt></a>&gt;::other::<a href="#const_reference495461441"><tt>const_reference</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Const metadata reference.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_reference583863863" id=
-"metadata_reference583863863">metadata_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#Allocator35940069"><tt>Allocator</tt></a>::<b>template</b> rebind&lt;
- <a href=
-"#metadata_type2849297114"><tt>metadata_type</tt></a>&gt;::other::reference
-</pre>
- </td>
-
- <td>
- <p>Metadata reference.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link12" id="link12">Protected Methods</a></h2>
-
- <h3><a name="link13" id="link13">Operators</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- <b>operator</b>()
- (<a href=
-"#node_iterator3431975247"><tt>node_iterator</tt></a> node_it,
- <a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> end_nd_it) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Updates the rank of a node through a <a href=
- "#node_iterator3431975247"><tt>node_iterator</tt></a>
- <span class="c1"><tt>node_it</tt></span>; <span class=
- "c1"><tt>end_nd_it</tt></span> is the end node <a href=
- "#iterator10418194"><tt>iterator</tt></a>.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link14" id="link14">Constructors, destructor, and
- related</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b>
- ~trie_order_statistics_node_update
- ()
-</pre>
- </td>
-
- <td>
- <p>Destructor.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link15" id="link15">Private Methods</a></h2>
-
- <h3><a name="link16" id="link16">Overrides</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <b>bool</b>
- empty
- () <b>const</b> = 0
-</pre>
- </td>
-
- <td>
- <p>Returns <tt><b>true</b></tt> if the container is
- empty.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href="#iterator10418194"><tt>iterator</tt></a>
- begin
- () = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#iterator10418194"><tt>iterator</tt></a> associated with
- the trie's first element.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href="#iterator10418194"><tt>iterator</tt></a>
- end
- () = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#iterator10418194"><tt>iterator</tt></a> associated with
- the trie's just-after-last element.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- node_begin
- () <b>const</b> = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- associated with the trie's root node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#node_iterator3431975247"><tt>node_iterator</tt></a>
- node_begin
- () = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#node_iterator3431975247"><tt>node_iterator</tt></a>
- associated with the trie's root node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- node_end
- () <b>const</b> = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- associated with a just-after leaf node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#node_iterator3431975247"><tt>node_iterator</tt></a>
- node_end
- () = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#node_iterator3431975247"><tt>node_iterator</tt></a>
- associated with a just-after leaf node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#e_access_traits1948190928"><tt>e_access_traits</tt></a> &amp;
- get_e_access_traits
- () = 0
-</pre>
- </td>
-
- <td>
- <p>Access to the cmp_fn object.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_prefix_search_node_update.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_prefix_search_node_update.html
deleted file mode 100644
index e136495c5..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_prefix_search_node_update.html
+++ /dev/null
@@ -1,628 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>trie_prefix_search_node_update Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>trie_prefix_search_node_update</tt> Interface</h1>
-
- <p>A node updater that allows tries to be searched for the
- range of values that match a certain prefix.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/trie_policy.hpp"><tt>trie_policy.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Template Parameters</a></h2>
-
- <table class="c1" width="100%" border="1" summary=
- "Template Parameters">
- <tr>
- <td width="20%" align="left"><b>Parameter</b></td>
-
- <td width="50%" align="left"><b>Description</b></td>
-
- <td width="30%" align="left"><b>Default Value</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Const_Node_Iterator1933878761" id=
-"Const_Node_Iterator1933878761"><b>class</b> Const_Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Const node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Node_Iterator4206909839" id=
-"Node_Iterator4206909839"><b>class</b> Node_Iterator</a>
-</pre>
- </td>
-
- <td>
- <p>Node iterator type.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="E_Access_Traits686553840" id=
-"E_Access_Traits686553840"><b>class</b> E_Access_Traits</a>
-</pre>
- </td>
-
- <td>
- <p>Comparison functor.</p>
- </td>
-
- <td>-</td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="Allocator35940069" id=
-"Allocator35940069"><b>class</b> Allocator</a>
-</pre>
- </td>
-
- <td>
- <p>Allocator type.</p>
- </td>
-
- <td>-</td>
- </tr>
- </table>
-
- <h2><a name="link2" id="link2">Public Types and
- Constants</a></h2>
-
- <h3><a name="link3" id="link3">Key-Type Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="key_type10393186" id="key_type10393186">key_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-The instantiating container's key type.
-</pre>
- </td>
-
- <td>
- <p>Key type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_key_reference3185471705" id=
-"const_key_reference3185471705">const_key_reference</a>
-</pre>
- </td>
-
- <td>
- <pre>
-The instantiating container's const key reference type.
-</pre>
- </td>
-
- <td>
- <p>Const key reference.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link4" id="link4">Policy Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="e_access_traits1948190928" id=
-"e_access_traits1948190928">e_access_traits</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#E_Access_Traits686553840"><tt>E_Access_Traits</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Element access traits.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_e_iterator2450008044" id=
-"const_e_iterator2450008044">const_e_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#e_access_traits1948190928"><tt>e_access_traits</tt></a>::const_iterator
-</pre>
- </td>
-
- <td>
- <p>Const element iterator.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="allocator48440069" id="allocator48440069">allocator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Allocator35940069"><tt>Allocator</tt></a>
-</pre>
- </td>
-
- <td>
- <p><a href="#Allocator35940069"><tt>Allocator</tt></a>
- type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link5" id="link5">General Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="size_type55424436" id="size_type55424436">size_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#allocator48440069"><tt>allocator</tt></a>::size_type
-</pre>
- </td>
-
- <td>
- <p>Size type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link6" id="link6">Metadata-Type
- Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="metadata_type2849297114" id=
-"metadata_type2849297114">metadata_type</a>
-</pre>
- </td>
-
- <td>
- <pre>
-__gnu_pbds::detail::null_node_metadata
-</pre>
- </td>
-
- <td>
- <p>Metadata type.</p>
- </td>
- </tr>
- </table>
-
- <h3><a name="link7" id="link7">Iterator Definitions</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Types">
- <tr>
- <td width="30%" align="left"><b>Type</b></td>
-
- <td width="55%" align="left"><b>Definition</b></td>
-
- <td width="15%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_node_iterator4205924553" id=
-"const_node_iterator4205924553">const_node_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href=
-"#Const_Node_Iterator1933878761"><tt>Const_Node_Iterator</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Const node iterator type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="node_iterator3431975247" id=
-"node_iterator3431975247">node_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<a href="#Node_Iterator4206909839"><tt>Node_Iterator</tt></a>
-</pre>
- </td>
-
- <td>
- <p>Node iterator type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="const_iterator98626788" id=
-"const_iterator98626788">const_iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>::value_type
-</pre>
- </td>
-
- <td>
- <p>Const iterator type.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a name="iterator10418194" id="iterator10418194">iterator</a>
-</pre>
- </td>
-
- <td>
- <pre>
-<b>typename</b> <a href=
-"#node_iterator3431975247"><tt>node_iterator</tt></a>::value_type
-</pre>
- </td>
-
- <td>
- <p>Iterator type.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link8" id="link8">Public Methods</a></h2>
-
- <h3><a name="link9" id="link9">Find Methods</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-std::pair&lt;
- <a href="#const_iterator98626788"><tt>const_iterator</tt></a>,
- <a href=
-"#const_iterator98626788"><tt>const_iterator</tt></a>&gt;
- prefix_range
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Finds the <tt><b>const</b></tt> <a href=
- "#iterator10418194"><tt>iterator</tt></a> range
- corresponding to all values whose prefixes match
- <span class="c1"><tt>r_key</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-std::pair&lt;
- <a href="#iterator10418194"><tt>iterator</tt></a>,
- <a href="#iterator10418194"><tt>iterator</tt></a>&gt;
- prefix_range
- (<a href=
-"#const_key_reference3185471705"><tt>const_key_reference</tt></a> r_key)
-</pre>
- </td>
-
- <td>
- <p>Finds the <a href=
- "#iterator10418194"><tt>iterator</tt></a> range
- corresponding to all values whose prefixes match
- <span class="c1"><tt>r_key</tt></span>.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-std::pair&lt;
- <a href="#const_iterator98626788"><tt>const_iterator</tt></a>,
- <a href=
-"#const_iterator98626788"><tt>const_iterator</tt></a>&gt;
- prefix_range
- (<a href=
-"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a> b,
- <a href=
-"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a> e) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Finds the <tt><b>const</b></tt> <a href=
- "#iterator10418194"><tt>iterator</tt></a> range
- corresponding to all values whose prefixes match [b,
- <span class="c1"><tt>e</tt></span>).</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-std::pair&lt;
- <a href="#iterator10418194"><tt>iterator</tt></a>,
- <a href="#iterator10418194"><tt>iterator</tt></a>&gt;
- prefix_range
- (<a href=
-"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a> b,
- <a href=
-"#const_e_iterator2450008044"><tt>const_e_iterator</tt></a> e)
-</pre>
- </td>
-
- <td>
- <p>Finds the <a href=
- "#iterator10418194"><tt>iterator</tt></a> range
- corresponding to all values whose prefixes match [b,
- <span class="c1"><tt>e</tt></span>).</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link10" id="link10">Protected Methods</a></h2>
-
- <h3><a name="link11" id="link11">Operators</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>inline</b> <b>void</b>
- <b>operator</b>()
- (<a href=
-"#node_iterator3431975247"><tt>node_iterator</tt></a> node_it,
- <a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a> end_nd_it) <b>const</b>
-</pre>
- </td>
-
- <td>
- <p>Called to update a node's metadata.</p>
- </td>
- </tr>
- </table>
-
- <h2><a name="link12" id="link12">Private Methods</a></h2>
-
- <h3><a name="link13" id="link13">Overrides</a></h3>
-
- <table class="c1" width="100%" border="1" summary="Methods">
- <tr>
- <td width="45%" align="left"><b>Method</b></td>
-
- <td width="55%" align="left"><b>Description</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#const_iterator98626788"><tt>const_iterator</tt></a>
- end
- () <b>const</b> = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <tt><b>const</b></tt> <a href=
- "#iterator10418194"><tt>iterator</tt></a> associated with
- the just-after last element.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href="#iterator10418194"><tt>iterator</tt></a>
- end
- () = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#iterator10418194"><tt>iterator</tt></a> associated with
- the just-after last element.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- node_begin
- () <b>const</b> = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- associated with the trie's root node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#node_iterator3431975247"><tt>node_iterator</tt></a>
- node_begin
- () = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#node_iterator3431975247"><tt>node_iterator</tt></a>
- associated with the trie's root node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- node_end
- () <b>const</b> = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#const_node_iterator4205924553"><tt>const_node_iterator</tt></a>
- associated with a just-after leaf node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <a href=
-"#node_iterator3431975247"><tt>node_iterator</tt></a>
- node_end
- () = 0
-</pre>
- </td>
-
- <td>
- <p>Returns the <a href=
- "#node_iterator3431975247"><tt>node_iterator</tt></a>
- associated with a just-after leaf node.</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<b>virtual</b> <b>const</b> <a href=
-"#e_access_traits1948190928"><tt>e_access_traits</tt></a> &amp;
- get_e_access_traits
- () <b>const</b> = 0
-</pre>
- </td>
-
- <td>
- <p>Access to the cmp_fn object.</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_tag.html
deleted file mode 100644
index 62bf12454..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trie_tag.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>trie_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>trie_tag</tt> Interface</h1>
-
- <p>Basic trie data structure tag.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
-
- <h2><a name="link1" id="link1">Base Classes</a></h2>
-
- <table class="c1" width="100%" border="1" summary="Bases">
- <tr>
- <td width="80%" align="left"><b>Class</b></td>
-
- <td width="20%" align="left"><b>Derivation Type</b></td>
- </tr>
-
- <tr>
- <td>
- <pre>
-<a href="basic_tree_tag.html"><span class=
-"c2"><tt>basic_tree_tag</tt></span></a>
-</pre>
- </td>
-
- <td>
- <p>public</p>
- </td>
- </tr>
- </table>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trivial_iterator_tag.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trivial_iterator_tag.html
deleted file mode 100644
index 1f59c5102..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/trivial_iterator_tag.html
+++ /dev/null
@@ -1,25 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>trivial_iterator_tag Interface</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1><tt>trivial_iterator_tag</tt> Interface</h1>
-
- <p>A \quot;trivial\quot; iterator tag. Signifies that the
- iterators has none of the STL's movement abilities.</p>
-
- <p>Defined in: <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/include/ext/pb_ds/tag_and_trait.hpp"><tt>tag_and_trait.hpp</tt></a></p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tutorial.html b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tutorial.html
deleted file mode 100644
index 152cd57b1..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/tutorial.html
+++ /dev/null
@@ -1,670 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
- <meta name="generator" content=
- "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />
-
- <title>Tutorial</title>
- <meta http-equiv="Content-Type" content=
- "text/html; charset=us-ascii" />
- </head>
-
-<body>
- <div id="page">
- <h1>Short Tutorial</h1>
-
- <p>Following is a short tutorial illustrating the main points
- of <tt>pb_ds</tt>. <a href="concepts.html">Concepts</a>
- describes and summarizes some concepts.</p>
-
- <h2><a name="assoc_main" id="assoc_main">Associative
- Containers</a></h2>
-
- <h3><a name="assoc_basic" id="assoc_basic">Basic Use</a></h3>
-
- <p>For the most part, <tt>pb_ds</tt>'s containers have the same
- interface as the STL's, except for the names used for the
- container classes themselves. For example, this shows basic
- operations on a collision-chaining hash-based container:</p>
-
- <pre>
-<a href=
-"cc_hash_table.html">cc_hash_table</a>&lt;<b>int</b>, <b>char</b>&gt; c;
-
-c[2] = 'b';
-
-assert(c.find(1) == c.end());
-</pre>
-
- <p>The container is called <a href=
- "cc_hash_table.html"><tt>cc_hash_table</tt></a> as
- opposed to <tt>unordered_map</tt>, since "unordered map" does
- not necessarily mean a hash-based map (as the STL implicitly
- implies). For example, list-based associative containers, which
- are very useful for the construction of "multimaps" (see
- <a href=
- "assoc_performance_tests.html#msc">Associative-Container
- Performance Tests::Observations::Mapping-Semantics
- Considerations</a>), are also unordered. It is also not called
- <tt>hash_map</tt> since there are more ways than one to
- implement hash tables.</p>
-
- <p>This snippet shows a red-black tree based container:</p>
- <pre>
-<a href=
-"tree.html">tree</a>&lt;<b>int</b>, <b>char</b>&gt; c;
-
-c[2] = 'b';
-
-assert(c.find(2) != c.end());
-</pre>
-
- <p>The container is called <a href=
- "tree.html"><tt>tree</tt></a>
- as opposed to <tt>map</tt>, since "map" doesn't say that
- much.</p>
-
- <p>Most of the STL's familiar methods are unchanged.
- <i>E.g.</i>, <tt>being</tt>, <tt>end</tt>, <tt>size</tt>,
- <tt>empty</tt>, and <tt>clear</tt>, do just the same as is
- customary. <a href=
- "assoc_examples.html#basic_usage">Associative-Container
- Examples::Basic use</a>, and especially <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_map.cc"><tt>basic_map.cc</tt></a>,
- show examples of this.</p>
-
-<p>This isn't to say that things are exactly as one would expect,
-given the container requirments and interfaces in the C++
-standard.</p>
-
-
- <p>The names of containers' policies and policy accessors are
- different than those of the STL. For example, if <tt>C</tt> is
- some type of hash-based container, then</p>
- <pre>
-C::hash_fn
-</pre>gives the type of its hash functor, and if <tt>c</tt> is some
-hash-based container object, then
- <pre>
-c.get_hash_fn()
-</pre>
-
- <p>will return a reference to its hash-functor object.</p>
-
- <p>Similarly, if <tt>C</tt> is some type of tree-based
- container, then</p>
- <pre>
-C::cmp_fn
-</pre>gives the type of its comparison functor, and if <tt>c</tt>
-is some tree-based container object, then
- <pre>
-c.get_cmp_fn()
-</pre>
-
- <p>will return a reference to its comparison-functor
- object.</p>
-
- <p>It would be nice to give names consistent with those in the
- existing C++ standard (inclusive of TR1). Unfortunately, these
- standard containers don't consistently name types and
- methods. For example, <tt>std::tr1::unordered_map</tt> uses
- <tt>hasher</tt> for the hash functor, but <tt>std::map</tt> uses
- <tt>key_compare</tt> for the comparison functor. Also, we could
- not find an accessor for <tt>std::tr1::unordered_map</tt>'s hash
- functor, but <tt>std::map</tt> uses <tt>compare</tt> for accessing
- the comparison functor.</p>
-
-<p>Instead, <tt>pb_ds</tt> attempts to be internally consistent, and
-uses standard-derived terminology if possible.
-</p>
-
- <p>Another source of difference is in scope: <tt>pb_ds</tt>
- contains more types of associative containers than the STL, and
- more opportunities to configure these new containers, since
- different types of associative containers are useful in different
- settings (see <a href=
- "assoc_performance_tests.html#dss_family_choice">Associative-Container
- Performance Tests::Observations::Underlying Data-Structure
- Families</a>).</p>
-
- <p><tt>pb_ds</tt> contains different classes for hash-based containers,
- tree-based containers, trie-based containers, and list-based
- containers. <a href=
- "interface.html#containers_assoc">Inteface::Containers::Associative
- Containers</a> lists the containers. <a href=
- "hash_based_containers.html">Design::Associative
- Containers::Hash-Based Containers</a>, <a href=
- "tree_based_containers.html">Design::Associative
- Containers::Tree-Based Containers</a>, <a href=
- "trie_based_containers.html">Design::Associative
- Containers::Trie-Based Containers</a>, and <a href=
- "lu_based_containers.html">Design::Associative
- Containers::List-Based Containers</a>, explain some more about
- these types of containers, respectively.</p>
-
- <p>Since associative containers share parts of their interface,
- they are organized as a class hierarchy; it is shown in Figure
- <a href="#cd">Class hierarchy</a>.</p>
-
- <h6 class="c1"><a name="cd" id="cd"><img src="container_cd.png" alt=
- "no image" /></a></h6>
-
- <h6 class="c1">Class hierarchy.</h6>
-
- <p>Each type or method is defined in the most-common ancestor
- in which it makes sense:
- <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_map.cc"><tt>basic_map.cc</tt></a>
- shows an example of most of the associative-container
- types.</p>
-
-
- <p>For example, all associative containers support iteration.
- Consequently, <a href=
- "container_base.html"><tt>container_base</tt></a> has the
- interface:</p>
- <pre>
-<b>template</b>&lt;...&gt;
-<b>class</b> <a href="container_base.html">container_base</a>
-{
- ...
-
-<b>public</b>:
- ...
-
- const_iterator
- begin() <b>const</b>;
-
- iterator
- begin();
-
- const_iterator
- end() <b>const</b>;
-
- iterator
- end();
-
- ...
-};
-</pre>
-
- <p>and so all associative containers inherent this method.
- Conversely, both collision-chaining and (general) probing
- hash-based associative containers have a hash functor, so
- <a href=
- "basic_hash_table.html"><tt>basic_hash_table</tt></a>
- has the interface:</p>
- <pre>
-<b>template</b>&lt;...&gt;
-<b>class</b> <a href="basic_hash_table.html">basic_hash_table</a> : <b>public</b> <a href="container_base.html">container_base</a>
-{
- ...
-
-<b>public</b>:
- ...
-
- const hash_fn&amp;
- get_hash_fn() const;
-
- hash_fn&amp;
- get_hash_fn();
- ...
-};
-</pre>
-
- <p>and so all hash-based associative containers inherit the
- same hash-functor accessor methods.</p>
-
- <p>This is discussed further in <a href=
- "ds_gen.html">Design::Associative Containers::Data-Structure
- Genericity</a>.</p>
-
- <h3><a name="assoc_policies" id="assoc_policies">Configuring
- Associative Containers</a></h3>
-
- <p>In general, each of <tt>pb_ds</tt>'s containers is
- parametrized by more policies than those of the STL's. For
- example, the STL's hash-based container is parametrized as
- follows:</p>
- <pre>
-<b>template</b>&lt;
- <b>typename</b> Key,
- <b>typename</b> Mapped,
- <b>typename</b> Hash,
- <b>typename</b> Pred,
- <b>typename</b> Allocator,
- <b>bool</b> Cache_Hashe_Code&gt;
-<b>class</b> unordered_map;
-</pre>
-
- <p>and so can be configured by key type, mapped type, a functor
- that translates keys to unsigned integral types, an equivalence
- predicate, an allocator, and an indicator whether to store hash
- values with each entry. <tt>pb_ds</tt>'s collision-chaining
- hash-based container is parametrized as</p>
- <pre>
-<b>template</b>&lt;
- <b>typename</b> Key,
- <b>typename</b> Mapped,
- <b>typename</b> Hash_Fn,
- <b>typename</b> Eq_Fn,
- <b>typename</b> Comb_Hash_Fn,
- <b>typename</b> Resize_Policy
- <b>bool</b> Store_Hash
- <b>typename</b> Allocator&gt;
-<b>class</b> <a href=
-"cc_hash_table.html">cc_hash_table</a>;
-</pre>
-
- <p>and so can be configured by the first four types of
- <tt>std::tr1::unordered_map</tt>, then a policy for translating
- the key-hash result into a position within the table, then a
- policy by which the table resizes, an indicator whether to
- store hash values with each entry, and an allocator (which is
- typically the last template parameter in STL containers).</p>
-
- <p>Nearly all policy parameters have default values, so this
- need not be considered for casual use. It is important to note,
- however, that hash-based containers' policies can dramatically
- alter their performance in different settings, and that
- tree-based containers' policies can make them useful for other
- purposes than just look-up.</p>
-
- <p><a href="hash_based_containers.html">Design::Associative
- Containers::Hash-Based Containers</a>, <a href=
- "tree_based_containers.html">Design::Associative
- Containers::Tree-Based Containers</a>, <a href=
- "trie_based_containers.html">Design::Associative
- Containers::Trie-Based Containers</a>, and <a href=
- "lu_based_containers.html">Design::Associative
- Containers::List-Based Containers</a>, explain some more about
- configuring hash based, tree based, trie based, and list base
- containers, respectively. <a href=
- "interface.html#ds_policy_classes">Interface::Container Policy
- Classes</a> shows the different policy classes for configuring
- associative containers. <a href=
- "assoc_examples.html#hash_based">Examples::Hash-Based
- Containers</a>, <a href=
- "assoc_examples.html#tree_like_based">Examples::Tree-Like-Based
- Containers</a>, and <a href=
- "assoc_examples.html#trie_based">Examples::Trie-Based
- Containers</a> show examples for this.</p>
-
- <h3><a name="assoc_ds_gen" id="assoc_ds_gen">Determining
- Containers' Attributes</a></h3>
-
- <p>Associative-containers' underlying data structures obviously
- affect their performance; Unfortunately, they can also affect
- their interface. When manipulating generically associative
- containers, it is often useful to be able to statically
- determine what they can support and what the cannot. (This was
- discussed in <a href=
- "motivation.html#assoc_ds_genericity">Motivation::Associative
- Containers::Data-Structure Genericity</a>.)</p>
-
- <p>Happily, the STL provides a good solution to a similar
- problem - that of the different behavior of iterators. If
- <tt>It</tt> is an iterator, then</p>
- <pre>
-<b>typename</b> std::iterator_traits&lt;It&gt;::iterator_category
-</pre>
-
- <p>is one of a small number of pre-defined
- <tt><b>struct</b></tt>s, and,</p>
- <pre>
-<b>typename</b> std::iterator_traits&lt;It&gt;::value_type
-</pre>
-
- <p>is the value type to which the iterator "points".</p>
-
- <p>Similarly, in <tt>pb_ds</tt>, if <tt>C</tt> is an
- associative container, then</p>
- <pre>
-<b>typename</b> <a href=
-"assoc_container_traits.html"><tt>container_traits</tt></a>&lt;C&gt;::container_category
-</pre>is one of a small number of pre-defined
-<tt><b>struct</b></tt>s, each one corresponding to a class in
-Figure <a href="#cd">Class hierarchy</a>. These tags are listed in
-<a href="interface.html#ds_ts_assoc">Interface::Associative
-Containers::Data-Structure Tags and Traits::Data-Structure
-Tags::Associative-Containers</a>; <a href="ds_gen.html#container_traits">
- Design::Associative Containers::Data-Structure Tags and
- Traits</a> explains this further; <a href=
- "ds_gen.html#tag_cd">Design::Associative
- Containers::Data-Structure Tags and Traits::Data-structure tag
- class hierarchy</a> shows a class diagram.
-
- <p>In most cases, however, the exact underlying data structure
- is not really important, but only one of its attributes:
- whether it guarantees storing elements by key order, for
- example. For this one can use</p>
- <pre>
-<b>typename</b> <a href=
-"assoc_container_traits.html"><tt>container_traits</tt></a>&lt;C&gt;::order_preserving
-</pre>
-
- <p>This is described further in <a href=
- "ds_gen.html">Design::Data-Structure Genericity</a>; <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/assoc_container_traits.cc"><tt>assoc_container_traits.cc</tt></a>
- shows an example of querying containers' attributes.</p>
-
- <h3><a name="assoc_find_range" id="assoc_find_range">Point-Type
- and Range-Type Methods and Iterators</a></h3>(This subsection
- addresses points from <a href=
- "motivation.html#assoc_diff_it">Motivation::Associative
- Containers::Differentiating between Iterator Types</a>.)
-
- <p><tt>pb_ds</tt> differentiates between two types of methods
- and iterators: point-type, and range-type. For example,
- <tt>find</tt> and <tt>insert</tt> are point-type methods, since
- they each deal with a specific element; their returned
- iterators are point-type iterators. <tt>begin</tt> and
- <tt>end</tt> are range-type methods, since they are not used to
- find a specific element, but rather to go over all elements in
- a container object; their returned iterators are range-type
- iterators.</p>
-
- <p>Most containers store elements in an order that is
- determined by their interface. Correspondingly, it is fine that
- their point-type iterators are synonymous with their range-type
- iterators. For example, in the following snippet</p>
- <pre>
-std::for_each(c.find(1), c.find(5), foo);
-</pre>two point-type iterators (returned by <tt>find</tt>) are used
-for a range-type purpose - going over all elements whose key is
-between 1 and 5.
-
- <p>Conversely, the above snippet makes no sense for
- self-organizing containers - ones that order (and reorder)
- their elements by implementation. It would be nice to have a
- uniform iterator system that would allow the above snippet to
- compile only if it made sense.</p>
-
- <p>This could trivially be done by specializing
- <tt>std::for_each</tt> for the case of iterators returned by
- <tt>std::tr1::unordered_map</tt>, but this would only solve the
- problem for one algorithm and one container. Fundamentally, the
- problem is that one can loop using a self-organizing
- container's point-type iterators.</p>
-
- <p><tt>pb_ds</tt>'s containers define two families of
- iterators: <tt>const_point_iterator</tt> and
- <tt>point_iterator</tt> are the iterator types returned by
- point-type methods; <tt>const_iterator</tt> and
- <tt>iterator</tt> are the iterator types returned by range-type
- methods.</p>
- <pre>
-<b>class</b> <i>&lt;- some container -&gt;</i>
-{
-<b>public</b>:
- ...
-
- <b>typedef</b> <i>&lt;- something -&gt;</i> const_iterator;
-
- <b>typedef</b> <i>&lt;- something -&gt;</i> iterator;
-
- <b>typedef</b> <i>&lt;- something -&gt;</i> const_point_iterator;
-
- <b>typedef</b> <i>&lt;- something -&gt;</i> point_iterator;
-
- ...
-
-<b>public</b>:
- ...
-
- const_iterator begin () <b>const</b>;
-
- iterator begin();
-
- const_point_iterator find(...) <b>const</b>;
-
- point_iterator find(...);
-};
-</pre>
-
- <p><a href="ds_gen.html#find_range">Design::Associative
- Containers::Data-Structure Genericity::Point-Type and
- Range-Type Methods and Iterators</a> discusses the relationship
- between point-type and range-type iterators in general; for
- containers whose interface defines sequence order, however, it
- is very simple: point-type and range-type iterators are exactly
- the same, which means that the above snippet will compile if it
- is used for an order-preserving associative container.</p>
-
- <p>For self-organizing containers, however, (hash-based
- containers as a special example), the preceding snippet will
- not compile, because their point-type iterators do not support
- <tt><b>operator</b>++</tt>.</p>
-
- <p>In any case, both for order-preserving and self-organizing
- containers, the following snippet will compile:</p>
- <pre>
-<b>typename</b> Cntnr::point_iterator it = c.find(2);
-</pre>
-
- <p>because a range-type iterator can always be converted to a
- point-type iterator.</p>
-
- <p><a href="ds_gen.html#find_range">Design::Associative
- Containers::Data-Structure Genericity::Point-Type and
- Range-Type Methods and Iterators</a> discusses this
- further.</p>
-
- <p><a href=
- "motivation.html#assoc_diff_it">Motivation::Associative
- Containers::Differentiating between Iterator Types</a> also
- raised the point that a container's iterators might have
- different invalidation rules concerning their de-referencing
- abilities and movement abilities. This now corresponds exactly
- to the question of whether point-type and range-type iterators
- are valid. As explained in <a href="#assoc_ds_gen">Determining
- Containers' Attributes</a>, <a href=
- "assoc_container_traits.html"><tt>container_traits</tt></a> allows
- querying a container for its data structure attributes. The
- iterator-invalidation guarantees are certainly a property of
- the underlying data structure, and so</p>
- <pre>
-<a href=
-"assoc_container_traits.html">container_traits</a>&lt;C&gt;::invalidation_guarantee
-</pre>
-
- <p>gives one of three pre-determined types that answer this
- query. This is explained further in <a href=
- "ds_gen.html#find_range">Design::Associative
- Containers::Data-Structure Genericity::Point-Type and
- Range-Type Methods and Iterators</a>.</p>
-
- <h3><a name="assoc_ms" id="assoc_ms">Distinguishing between Maps and Sets</a></h3>
-
- <p>Anyone familiar with the STL knows that there are four kinds
- of associative containers: maps, sets, multimaps, and
- multisets. <a href="#assoc_basic">Basic Use</a> discussed how
- to use maps, <i>i.e.</i> containers that associate each key to
- some data.</p>
-
- <p>Sets are associative containers that simply store keys -
- they do not map them to anything. In the STL, each map class
- has a corresponding set class. <i>E.g.</i>,
- <tt>std::map&lt;<b>int</b>, <b>char</b>&gt;</tt> maps each
- <tt><b>int</b></tt> to a <tt><b>char</b></tt>, but
- <tt>std::set&lt;<b>int</b>, <b>char</b>&gt;</tt> simply stores
- <tt><b>int</b></tt>s. In <tt>pb_ds</tt>, however, there are no
- distinct classes for maps and sets. Instead, an associative
- container's <tt>Mapped</tt> template parameter is a policy: if
- it is instantiated by <a href=
- "null_mapped_type.html"><tt>null_mapped_type</tt></a>, then it
- is a "set"; otherwise, it is a "map". <i>E.g.</i>,</p>
- <pre>
-<a href="cc_hash_table.html">cc_hash_table</a>&lt;<b>int</b>, <b>char</b>&gt;
-</pre>is a "map" mapping each <tt><b>int</b></tt> value to a <tt>
- <b>char</b></tt>, but
- <pre>
-<a href="cc_hash_table.html">cc_hash_table</a>&lt;<b>int</b>, <a href="null_mapped_type.html">null_mapped_type</a>&gt;
-</pre>is a type that uniquely stores <tt><b>int</b></tt> values.
-
- <p>Once the <tt>Mapped</tt> template parameter is instantiated
- by <a href="null_mapped_type.html">null_mapped_type</a>, then
- the "set" acts very similarly to the STL's sets - it does not
- map each key to a distinct <a href=
- "null_mapped_type.html">null_mapped_type</a> object. Also,
- , the container's <tt>value_type</tt> is essentially
- its <tt>key_type</tt> - just as with the STL's sets. For a simple example, see <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_set.cc"><tt>basic_set.cc</tt></a>
- .</p>
-
- <p>The STL's multimaps and multisets allow, respectively,
- non-uniquely mapping keys and non-uniquely storing keys. As
- discussed in <a href=
- "motivation.html#assoc_mapping_semantics">Motivation::Associative
- Containers::Alternative to Multiple Equivalent Keys</a>, the
- reasons why this might be necessary are 1) that a key might be
- decomposed into a primary key and a secondary key, 2) that a
- key might appear more than once, or 3) any arbitrary
- combination of 1)s and 2)s. Correspondingly,
- one should use 1) "maps" mapping primary keys to secondary
- keys, 2) "maps" mapping keys to size types, or 3) any arbitrary
- combination of 1)s and 2)s. Thus, for example, an
- <tt>std::multiset&lt;<b>int</b>&gt;</tt> might be used to store
- multiple instances of integers, but using <tt>pb_ds</tt>'s
- containers, one might use</p>
- <pre>
-<a href=
-"tree.html">tree</a>&lt;<b>int</b>, size_t&gt;
-</pre><i>i.e.</i>, a "map" of <tt><b>int</b></tt>s to
-<tt>size_t</tt>s.
-
- <p><a href="assoc_examples.html#mmaps">Associative-Container
- Examples::"Multimaps" and "Multisets"</a> shows some simple
- examples.</p>
-
- <p>These "multimaps" and "multisets" might be confusing to
- anyone familiar with the STL's <tt>std::multimap</tt> and
- <tt>std::multiset</tt>, because there is no clear
- correspondence between the two. For example, in some cases
- where one uses <tt>std::multiset</tt> in the STL, one might use
- in <tt>pb_ds</tt> a "multimap" of "multisets" - <i>i.e.</i>, a
- container that maps primary keys each to an associative
- container that maps each secondary key to the number of times
- it occurs.</p>
-
- <p>When one uses a "multimap," one should choose with care the
- type of container used for secondary keys. This is further
- explained in <a href=
- "assoc_performance_tests.html#msc">Associative-Container
- Performance Tests::Observations::Mapping-Semantics
- Considerations</a>.</p>
-
-<hr>
- <h2><a name="pq" id="pq">Priority Queues</a></h2>
-
- <h3><a name="pq_basic" id="pq_basic">Basic Use</a></h3>
-
- <p><tt>pb_ds</tt>'s priority_queue container is
- similar to the STL's in interface. For example:</p>
- <pre>
-<a href=
-"priority_queue.html">priority_queue</a>&lt;<b>int</b>&gt; p;
-
-p.push(2);
-p.push(4);
-p.push(1);
-
-assert(p.top() == 4);
-
-p.pop();
-
-assert(p.top() == 2);
-
-assert(p.size() == 2);
-assert(!p.empty());
-</pre>
-
- <h3><a name="pq_policies" id="pq_policies">Configuring Priority
- Queues</a></h3>
-
- <p>As opposed to associative containers, priority queues have
- relatively few configuration options. The priority queue is
- parametrized as follows:</p>
- <pre>
-<b>template</b>&lt;
- <b>typename</b> Value_Type,
- <b>typename</b> Cmp_Fn,
- <b>typename</b> Tag,
- <b>typename</b> Allocator&gt;
-<b>class</b> <a href="priority_queue.html">priority_queue</a>;
-</pre>
-
- <p>The <tt>Value_Type</tt>, <tt>Cmp_Fn</tt>, and
- <tt>Allocator</tt> parameters are the container's value type,
- comparison-functor type, and allocator type, respectively;
- these are very similar to the STL's priority queue. The
- <tt>Tag</tt> parameter is different: there are a number of
- pre-defined tag types corresponding to binary heaps, binomial
- heaps, <i>etc.</i>, and <tt>Tag</tt> should be instantiated
- by one of them. <a href=
- "interface.html#ds_ts_pq">Interface::Data-Structure Tags and
- Traits::Data Structure Tags::Priority-Queues</a> lists the
- possible types, <a href="pq_design.html">Priority-Queue
- Design</a> explains this further, and <a href=
- "http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/testsuite/ext/pb_ds/example/basic_priority_queue.cc"><tt>basic_priority_queue.cc</tt></a>
- shows an example.</p>
-
- <p>Note that as opposed to the STL's priority queue, <a href=
- "priority_queue.html"><tt>priority_queue</tt></a> is not a
- sequence-adapter; it is a regular container.</p>
-
- <h3><a name="pq_ds_more_ops" id="pq_ds_more_ops">Supporting
- More Operations</a></h3>
-
- <p><a href="priority_queue.html"><tt>priority_queue</tt></a>'s
- <tt>push</tt> method returns a point-type iterator, which can
- be used for modifying or erasing arbitrary values. For
- example:</p>
- <pre>
-<a href=
-"priority_queue.html">priority_queue</a>&lt;<b>int</b>&gt; p;
-
-<a href=
-"priority_queue.html">priority_queue</a>&lt;<b>int</b>&gt;::point_iterator it = p.push(3);
-
-p.modify(it, 4);
-</pre>
-
- <p>These types of operations are necessary for making priority
- queues useful for different applications, especially graph
- applications. <a href="pq_examples.html#xref">Priority-Queue
- Examples::Cross-Referencing</a> gives some examples.</p>
-
- <h3><a name="pq_ds_gen" id="pq_ds_gen">Determining Container
- Attributes</a></h3>
-
- <p>Similarly to <a href=
- "assoc_container_traits.html"><tt>container_traits</tt></a> (described
- in <a href="#assoc_ds_gen">Associative Containers::Determining
- Containers' Attributes</a>), <a href=
- "pq_container_traits.html"><tt>container_traits</tt></a> can be used to
- statically determine priority-queues' attributes:</p>
- <pre>
-<a href=
-"pq_container_traits.html">container_traits</a>&lt;C&gt;::container_category
-</pre>is one of a small number of predefined tag structures that
-identifies the underlying data structure, and
- <pre>
-<a href=
-"pq_container_traits.html">container_traits</a>&lt;C&gt;::invalidation_guarantee
-</pre>
-
- <p>is its invalidation guarantee. Invalidation guarantees are
- especially important regarding priority queues, since in
- <tt>pb_ds</tt>'s design, iterators are practically the only way
- to manipulate them.</p>
-
- <p><a href="pq_design.html#pq_traits">Design::Priority
- Queues::Traits</a> discusses this further. <a href=
- "pq_examples.html#generics">Priority-Queue
- Examples::Generics</a> shows an example.</p>
- </div>
-</body>
-</html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_policy_cd.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_policy_cd.png
deleted file mode 100644
index 115a751c3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_policy_cd.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_seq_diagram.png b/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_seq_diagram.png
deleted file mode 100644
index 880a50edf..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/ext/pb_ds/update_seq_diagram.png
+++ /dev/null
Binary files differ
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/faq.html b/gcc-4.4.3/libstdc++-v3/doc/html/faq.html
deleted file mode 100644
index 74fa9fa54..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/faq.html
+++ /dev/null
@@ -1,874 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Frequently Asked Questions</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><link rel="home" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk03.html" title="" /><link rel="prev" href="bk03.html" title="" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Frequently Asked Questions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk03.html">Prev</a> </td><th width="60%" align="center"></th><td width="20%" align="right"> </td></tr></table><hr /></div><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="faq"></a>Frequently Asked Questions</h2></div><div><p class="copyright">Copyright ©
- 2008
-
- <a class="ulink" href="http://fsf.org" target="_top">FSF</a>
- </p></div></div><hr /></div><div class="qandaset"><dl><dt>1. <a href="faq.html#faq.info">General Information</a></dt><dd><dl><dt>1.1. <a href="faq.html#faq.what">
- What is libstdc++?
- </a></dt><dt>1.2. <a href="faq.html#faq.why">
- Why should I use libstdc++?
- </a></dt><dt>1.3. <a href="faq.html#faq.who">
- Who's in charge of it?
- </a></dt><dt>1.4. <a href="faq.html#faq.when">
- When is libstdc++ going to be finished?
- </a></dt><dt>1.5. <a href="faq.html#faq.how">
- How do I contribute to the effort?
- </a></dt><dt>1.6. <a href="faq.html#faq.whereis_old">
- What happened to the older libg++? I need that!
- </a></dt><dt>1.7. <a href="faq.html#faq.more_questions">
- What if I have more questions?
- </a></dt></dl></dd><dt>2. <a href="faq.html#faq.license">License</a></dt><dd><dl><dt>2.1. <a href="faq.html#faq.license.what">
- What are the license terms for libstdc++?
- </a></dt><dt>2.2. <a href="faq.html#faq.license.any_program">
- So any program which uses libstdc++ falls under the GPL?
- </a></dt><dt>2.3. <a href="faq.html#faq.license.lgpl">
- How is that different from the GNU {Lesser,Library} GPL?
- </a></dt><dt>2.4. <a href="faq.html#faq.license.what_restrictions">
- I see. So, what restrictions are there on programs that use the library?
- </a></dt></dl></dd><dt>3. <a href="faq.html#faq.installation">Installation</a></dt><dd><dl><dt>3.1. <a href="faq.html#faq.how_to_install">How do I install libstdc++?
- </a></dt><dt>3.2. <a href="faq.html#faq.how_to_get_sources">How does one get current libstdc++ sources?
- </a></dt><dt>3.3. <a href="faq.html#faq.how_to_test">How do I know if it works?
- </a></dt><dt>3.4. <a href="faq.html#faq.how_to_set_paths">How do I insure that the dynamically linked library will be found?
- </a></dt><dt>3.5. <a href="faq.html#faq.what_is_libsupcxx">
- What's libsupc++?
- </a></dt><dt>3.6. <a href="faq.html#faq.size">
- This library is HUGE!
- </a></dt></dl></dd><dt>4. <a href="faq.html#faq.platform-specific">Platform-Specific Issues</a></dt><dd><dl><dt>4.1. <a href="faq.html#faq.other_compilers">
- Can libstdc++ be used with non-GNU compilers?
- </a></dt><dt>4.2. <a href="faq.html#faq.solaris_long_long">
- No 'long long' type on Solaris?
- </a></dt><dt>4.3. <a href="faq.html#faq.predefined">
- _XOPEN_SOURCE and _GNU_SOURCE are always defined?
- </a></dt><dt>4.4. <a href="faq.html#faq.darwin_ctype">
- Mac OS X ctype.h is broken! How can I fix it?
- </a></dt><dt>4.5. <a href="faq.html#faq.threads_i386">
- Threading is broken on i386?
- </a></dt><dt>4.6. <a href="faq.html#faq.atomic_mips">
- MIPS atomic operations
- </a></dt><dt>4.7. <a href="faq.html#faq.linux_glibc">
- Recent GNU/Linux glibc required?
- </a></dt><dt>4.8. <a href="faq.html#faq.freebsd_wchar">
- Can't use wchar_t/wstring on FreeBSD
- </a></dt></dl></dd><dt>5. <a href="faq.html#faq.known_bugs">Known Bugs</a></dt><dd><dl><dt>5.1. <a href="faq.html#faq.what_works">
- What works already?
- </a></dt><dt>5.2. <a href="faq.html#faq.standard_bugs">
- Bugs in the ISO C++ language or library specification
- </a></dt><dt>5.3. <a href="faq.html#faq.compiler_bugs">
- Bugs in the compiler (gcc/g++) and not libstdc++
- </a></dt></dl></dd><dt>6. <a href="faq.html#faq.known_non-bugs">Known Non-Bugs</a></dt><dd><dl><dt>6.1. <a href="faq.html#faq.stream_reopening_fails">
- Reopening a stream fails
- </a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose">
- -Weffc++ complains too much
- </a></dt><dt>6.3. <a href="faq.html#faq.ambiguous_overloads">
- Ambiguous overloads after including an old-style header
- </a></dt><dt>6.4. <a href="faq.html#faq.v2_headers">
- The g++-3 headers are not ours
- </a></dt><dt>6.5. <a href="faq.html#faq.boost_concept_checks">
- Errors about *Concept and
- constraints in the STL
- </a></dt><dt>6.6. <a href="faq.html#faq.dlopen_crash">
- Program crashes when using library code in a
- dynamically-loaded library
- </a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">
- “Memory leaks” in containers
- </a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">
- list::size() is O(n)!
- </a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
- Aw, that's easy to fix!
- </a></dt></dl></dd><dt>7. <a href="faq.html#faq.misc">Miscellaneous</a></dt><dd><dl><dt>7.1. <a href="faq.html#faq.iterator_as_pod">
- string::iterator is not char*; vector&lt;T&gt;::iterator is not T*
- </a></dt><dt>7.2. <a href="faq.html#faq.what_is_next">
- What's next after libstdc++?
- </a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl">
- What about the STL from SGI?
- </a></dt><dt>7.4. <a href="faq.html#faq.extensions_and_backwards_compat">
- Extensions and Backward Compatibility
- </a></dt><dt>7.5. <a href="faq.html#faq.tr1_support">
- Does libstdc++ support TR1?
- </a></dt><dt>7.6. <a href="faq.html#faq.get_iso_cxx">How do I get a copy of the ISO C++ Standard?
- </a></dt><dt>7.7. <a href="faq.html#faq.what_is_abi">
- What's an ABI and why is it so messy?
- </a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity">
- How do I make std::vector&lt;T&gt;::capacity() == std::vector&lt;T&gt;::size?
- </a></dt></dl></dd></dl><table border="0" summary="Q and A Set"><col align="left" width="1%" /><tbody><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.info"></a>1. General Information</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>1.1. <a href="faq.html#faq.what">
- What is libstdc++?
- </a></dt><dt>1.2. <a href="faq.html#faq.why">
- Why should I use libstdc++?
- </a></dt><dt>1.3. <a href="faq.html#faq.who">
- Who's in charge of it?
- </a></dt><dt>1.4. <a href="faq.html#faq.when">
- When is libstdc++ going to be finished?
- </a></dt><dt>1.5. <a href="faq.html#faq.how">
- How do I contribute to the effort?
- </a></dt><dt>1.6. <a href="faq.html#faq.whereis_old">
- What happened to the older libg++? I need that!
- </a></dt><dt>1.7. <a href="faq.html#faq.more_questions">
- What if I have more questions?
- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what"></a><a id="faq.what.q"></a><p><b>1.1.</b></p></td><td align="left" valign="top"><p>
- What is libstdc++?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.what.a"></a></td><td align="left" valign="top"><p>
- The GNU Standard C++ Library v3 is an ongoing project to
- implement the ISO 14882 Standard C++ library as described in
- chapters 17 through 27 and annex D. For those who want to see
- exactly how far the project has come, or just want the latest
- bleeding-edge code, the up-to-date source is available over
- anonymous SVN, and can even be browsed over
- the <a class="ulink" href="http://gcc.gnu.org/svn.html" target="_top">web</a>.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.why"></a><a id="q-why"></a><p><b>1.2.</b></p></td><td align="left" valign="top"><p>
- Why should I use libstdc++?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-why"></a></td><td align="left" valign="top"><p>
- The completion of the ISO C++ standardization gave the C++
- community a powerful set of reuseable tools in the form of the C++
- Standard Library. However, all existing C++ implementations are
- (as the Draft Standard used to say) “<span class="quote">incomplet and
- incorrekt</span>”, and many suffer from limitations of the compilers
- that use them.
- </p><p>
- The GNU compiler collection
- (<span class="command"><strong>gcc</strong></span>, <span class="command"><strong>g++</strong></span>, etc) is widely
- considered to be one of the leading compilers in the world. Its
- development is overseen by the
- <a class="ulink" href="http://gcc.gnu.org/" target="_top">GCC team</a>. All of
- the rapid development and near-legendary
- <a class="ulink" href="http://gcc.gnu.org/buildstat.html" target="_top">portability</a>
- that are the hallmarks of an open-source project are being
- applied to libstdc++.
- </p><p>
- That means that all of the Standard classes and functions will be
- freely available and fully compliant. (Such as
- <code class="classname">string</code>,
- <code class="classname">vector&lt;&gt;</code>, iostreams, and algorithms.)
- Programmers will no longer need to “<span class="quote">roll their own</span>”
- nor be worried about platform-specific incompatibilities.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.who"></a><a id="q-who"></a><p><b>1.3.</b></p></td><td align="left" valign="top"><p>
- Who's in charge of it?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-who"></a></td><td align="left" valign="top"><p>
- The libstdc++ project is contributed to by several developers
- all over the world, in the same way as GCC or Linux.
- Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, Ulrich Drepper,
- Loren James Rittle, and Paolo Carlini are the lead maintainers of
- the SVN archive.
- </p><p>
- Development and discussion is held on the libstdc++ mailing
- list. Subscribing to the list, or searching the list
- archives, is open to everyone. You can read instructions for
- doing so on the <a class="ulink" href="http://gcc.gnu.org/libstdc++/" target="_top">homepage</a>.
- If you have questions, ideas, code, or are just curious, sign up!
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.when"></a><a id="q-when"></a><p><b>1.4.</b></p></td><td align="left" valign="top"><p>
- When is libstdc++ going to be finished?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-when"></a></td><td align="left" valign="top"><p>
- Nathan Myers gave the best of all possible answers, responding to
- a Usenet article asking this question: <span class="emphasis"><em>Sooner, if you
- help.</em></span>
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how"></a><a id="q-how"></a><p><b>1.5.</b></p></td><td align="left" valign="top"><p>
- How do I contribute to the effort?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how"></a></td><td align="left" valign="top"><p>
- Here is <a class="link" href="manual/appendix_contributing.html" title="Appendix A.  Contributing">a page devoted to
- this topic</a>. Subscribing to the mailing list (see above, or
- the homepage) is a very good idea if you have something to
- contribute, or if you have spare time and want to
- help. Contributions don't have to be in the form of source code;
- anybody who is willing to help write documentation, for example,
- or has found a bug in code that we all thought was working and is
- willing to provide details, is more than welcome!
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.whereis_old"></a><a id="q-whereis_old"></a><p><b>1.6.</b></p></td><td align="left" valign="top"><p>
- What happened to the older libg++? I need that!
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-whereis_old"></a></td><td align="left" valign="top"><p>
- The most recent libg++ README states that libg++ is no longer
- being actively maintained. It should not be used for new
- projects, and is only being kicked along to support older code.
- </p><p>
- More information in the <a class="link" href="manual/backwards.html" title="Backwards Compatibility">backwards compatibility documentation</a>
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.more_questions"></a><a id="q-more_questions"></a><p><b>1.7.</b></p></td><td align="left" valign="top"><p>
- What if I have more questions?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-more_questions"></a></td><td align="left" valign="top"><p>
- If you have read the README file, and your question remains
- unanswered, then just ask the mailing list. At present, you do not
- need to be subscribed to the list to send a message to it. More
- information is available on the homepage (including how to browse
- the list archives); to send a message to the list,
- use <code class="email">&lt;<a class="email" href="mailto:libstdc++@gcc.gnu.org">libstdc++@gcc.gnu.org</a>&gt;</code>.
- </p><p>
- If you have a question that you think should be included
- here, or if you have a question <span class="emphasis"><em>about</em></span> a question/answer
- here, please send email to the libstdc++ mailing list, as above.
- </p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.license"></a>2. License</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>2.1. <a href="faq.html#faq.license.what">
- What are the license terms for libstdc++?
- </a></dt><dt>2.2. <a href="faq.html#faq.license.any_program">
- So any program which uses libstdc++ falls under the GPL?
- </a></dt><dt>2.3. <a href="faq.html#faq.license.lgpl">
- How is that different from the GNU {Lesser,Library} GPL?
- </a></dt><dt>2.4. <a href="faq.html#faq.license.what_restrictions">
- I see. So, what restrictions are there on programs that use the library?
- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.what"></a><a id="q-license.what"></a><p><b>2.1.</b></p></td><td align="left" valign="top"><p>
- What are the license terms for libstdc++?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what"></a></td><td align="left" valign="top"><p>
- See <a class="link" href="manual/license.html" title="License">our license description</a>
- for these and related questions.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.any_program"></a><a id="q-license.any_program"></a><p><b>2.2.</b></p></td><td align="left" valign="top"><p>
- So any program which uses libstdc++ falls under the GPL?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.any_program"></a></td><td align="left" valign="top"><p>
- No. The special exception permits use of the library in
- proprietary applications.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.lgpl"></a><a id="q-license.lgpl"></a><p><b>2.3.</b></p></td><td align="left" valign="top"><p>
- How is that different from the GNU {Lesser,Library} GPL?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.lgpl"></a></td><td align="left" valign="top"><p>
- The LGPL requires that users be able to replace the LGPL code with a
- modified version; this is trivial if the library in question is a C
- shared library. But there's no way to make that work with C++, where
- much of the library consists of inline functions and templates, which
- are expanded inside the code that uses the library. So to allow people
- to replace the library code, someone using the library would have to
- distribute their own source, rendering the LGPL equivalent to the GPL.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.what_restrictions"></a><a id="q-license.what_restrictions"></a><p><b>2.4.</b></p></td><td align="left" valign="top"><p>
- I see. So, what restrictions are there on programs that use the library?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what_restrictions"></a></td><td align="left" valign="top"><p>
- None. We encourage such programs to be released as open source,
- but we won't punish you or sue you if you choose otherwise.
- </p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.installation"></a>3. Installation</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>3.1. <a href="faq.html#faq.how_to_install">How do I install libstdc++?
- </a></dt><dt>3.2. <a href="faq.html#faq.how_to_get_sources">How does one get current libstdc++ sources?
- </a></dt><dt>3.3. <a href="faq.html#faq.how_to_test">How do I know if it works?
- </a></dt><dt>3.4. <a href="faq.html#faq.how_to_set_paths">How do I insure that the dynamically linked library will be found?
- </a></dt><dt>3.5. <a href="faq.html#faq.what_is_libsupcxx">
- What's libsupc++?
- </a></dt><dt>3.6. <a href="faq.html#faq.size">
- This library is HUGE!
- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_install"></a><a id="q-how_to_install"></a><p><b>3.1.</b></p></td><td align="left" valign="top"><p>How do I install libstdc++?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_install"></a></td><td align="left" valign="top"><p>
- Often libstdc++ comes pre-installed as an integral part of many
- existing Linux and Unix systems, as well as many embedded
- development tools. It may be necessary to install extra
- development packages to get the headers, or the documentation, or
- the source: please consult your vendor for details.
- </p><p>
- To build and install from the GNU GCC sources, please consult the
- <a class="link" href="manual/setup.html" title="Chapter 2. Setup">setup
- documentation</a> for detailed
- instructions. You may wish to browse those files ahead
- of time to get a feel for what's required.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_get_sources"></a><a id="q-how_to_get_sources"></a><p><b>3.2.</b></p></td><td align="left" valign="top"><p>How does one get current libstdc++ sources?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_get_sources"></a></td><td align="left" valign="top"><p>
- Libstdc++ sources for all official releases can be obtained as
- part of the GCC sources, available from various sites and
- mirrors. A full <a class="ulink" href="http://gcc.gnu.org/mirrors.html" target="_top">list of
- download sites</a> is provided on the main GCC site.
- </p><p>
- Current libstdc++ sources can always be checked out of the main
- GCC source repository using the appropriate version control
- tool. At this time, that tool
- is <span class="application">Subversion</span>.
- </p><p>
- <span class="application">Subversion</span>, or <acronym class="acronym">SVN</acronym>, is
- one of several revision control packages. It was selected for GNU
- projects because it's free (speech), free (beer), and very high
- quality. The <a class="ulink" href="http://subversion.tigris.org" target="_top"> Subversion
- home page</a> has a better description.
- </p><p>
- The “<span class="quote">anonymous client checkout</span>” feature of SVN is
- similar to anonymous FTP in that it allows anyone to retrieve
- the latest libstdc++ sources.
- </p><p>
- For more information
- see <a class="ulink" href="http://gcc.gnu.org/svn.html" target="_top"><acronym class="acronym">SVN</acronym>
- details</a>.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_test"></a><a id="q-how_to_test"></a><p><b>3.3.</b></p></td><td align="left" valign="top"><p>How do I know if it works?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_test"></a></td><td align="left" valign="top"><p>
- Libstdc++ comes with its own validation testsuite, which includes
- conformance testing, regression testing, ABI testing, and
- performance testing. Please consult the
- <a class="ulink" href="http://gcc.gnu.org/install/test.html" target="_top">testing
- documentation</a> for more details.
- </p><p>
- If you find bugs in the testsuite programs themselves, or if you
- think of a new test program that should be added to the suite,
- <span class="emphasis"><em>please</em></span> write up your idea and send it to the list!
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_set_paths"></a><a id="q-how_to_set_paths"></a><p><b>3.4.</b></p></td><td align="left" valign="top"><p>How do I insure that the dynamically linked library will be found?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_set_paths"></a></td><td align="left" valign="top"><p>
- Depending on your platform and library version, the error message might
- be similar to one of the following:
- </p><pre class="screen">
- ./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
-
- /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found
- </pre><p>
- This doesn't mean that the shared library isn't installed, only
- that the dynamic linker can't find it. When a dynamically-linked
- executable is run the linker finds and loads the required shared
- libraries by searching a pre-configured list of directories. If
- the directory where you've installed libstdc++ is not in this list
- then the libraries won't be found. The simplest way to fix this is
- to use the <code class="literal">LD_LIBRARY_PATH</code> environment variable,
- which is a colon-separated list of directories in which the linker
- will search for shared libraries:
- </p><pre class="screen">
- LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH
- export LD_LIBRARY_PATH
- </pre><p>
- The exact environment variable to use will depend on your
- platform, e.g. DYLD_LIBRARY_PATH for Darwin,
- LD_LIBRARY_PATH_32/LD_LIBRARY_PATH_64 for Solaris 32-/64-bit,
- LD_LIBRARYN32_PATH/LD_LIBRARY64_PATH for Irix N32/64-bit ABIs and
- SHLIB_PATH for HP-UX.
- </p><p>
- See the man pages for <span class="command"><strong>ld</strong></span>, <span class="command"><strong>ldd</strong></span>
- and <span class="command"><strong>ldconfig</strong></span> for more information. The dynamic
- linker has different names on different platforms but the man page
- is usually called something such as <code class="filename">ld.so/rtld/dld.so</code>.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_libsupcxx"></a><a id="q-what_is_libsupcxx"></a><p><b>3.5.</b></p></td><td align="left" valign="top"><p>
- What's libsupc++?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_libsupcxx"></a></td><td align="left" valign="top"><p>
- If the only functions from <code class="filename">libstdc++.a</code>
- which you need are language support functions (those listed in
- <a class="link" href="manual/support.html" title="Part II.  Support">clause 18</a> of the
- standard, e.g., <code class="function">new</code> and
- <code class="function">delete</code>), then try linking against
- <code class="filename">libsupc++.a</code>, which is a subset of
- <code class="filename">libstdc++.a</code>. (Using <span class="command"><strong>gcc</strong></span>
- instead of <span class="command"><strong>g++</strong></span> and explicitly linking in
- <code class="filename">libsupc++.a</code> via <code class="literal">-lsupc++</code>
- for the final link step will do it). This library contains only
- those support routines, one per object file. But if you are
- using anything from the rest of the library, such as IOStreams
- or vectors, then you'll still need pieces from
- <code class="filename">libstdc++.a</code>.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.size"></a><a id="q-size"></a><p><b>3.6.</b></p></td><td align="left" valign="top"><p>
- This library is HUGE!
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size"></a></td><td align="left" valign="top"><p>
- Usually the size of libraries on disk isn't noticeable. When a
- link editor (or simply “<span class="quote">linker</span>”) pulls things from a
- static archive library, only the necessary object files are copied
- into your executable, not the entire library. Unfortunately, even
- if you only need a single function or variable from an object file,
- the entire object file is extracted. (There's nothing unique to C++
- or libstdc++ about this; it's just common behavior, given here
- for background reasons.)
- </p><p>
- Some of the object files which make up libstdc++.a are rather large.
- If you create a statically-linked executable with
- <code class="literal">-static</code>, those large object files are suddenly part
- of your executable. Historically the best way around this was to
- only place a very few functions (often only a single one) in each
- source/object file; then extracting a single function is the same
- as extracting a single .o file. For libstdc++ this is only
- possible to a certain extent; the object files in question contain
- template classes and template functions, pre-instantiated, and
- splitting those up causes severe maintenance headaches.
- </p><p>
- On supported platforms, libstdc++ takes advantage of garbage
- collection in the GNU linker to get a result similar to separating
- each symbol into a separate source and object files. On these platforms,
- GNU ld can place each function and variable into its own
- section in a .o file. The GNU linker can then perform garbage
- collection on unused sections; this reduces the situation to only
- copying needed functions into the executable, as before, but all
- happens automatically.
- </p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.platform-specific"></a>4. Platform-Specific Issues</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>4.1. <a href="faq.html#faq.other_compilers">
- Can libstdc++ be used with non-GNU compilers?
- </a></dt><dt>4.2. <a href="faq.html#faq.solaris_long_long">
- No 'long long' type on Solaris?
- </a></dt><dt>4.3. <a href="faq.html#faq.predefined">
- _XOPEN_SOURCE and _GNU_SOURCE are always defined?
- </a></dt><dt>4.4. <a href="faq.html#faq.darwin_ctype">
- Mac OS X ctype.h is broken! How can I fix it?
- </a></dt><dt>4.5. <a href="faq.html#faq.threads_i386">
- Threading is broken on i386?
- </a></dt><dt>4.6. <a href="faq.html#faq.atomic_mips">
- MIPS atomic operations
- </a></dt><dt>4.7. <a href="faq.html#faq.linux_glibc">
- Recent GNU/Linux glibc required?
- </a></dt><dt>4.8. <a href="faq.html#faq.freebsd_wchar">
- Can't use wchar_t/wstring on FreeBSD
- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.other_compilers"></a><a id="q-other_compilers"></a><p><b>4.1.</b></p></td><td align="left" valign="top"><p>
- Can libstdc++ be used with non-GNU compilers?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-other_compilers"></a></td><td align="left" valign="top"><p>
- Perhaps.
- </p><p>
- Since the goal of ISO Standardization is for all C++
- implementations to be able to share code, libstdc++ should be
- usable under any ISO-compliant compiler, at least in theory.
- </p><p>
- However, the reality is that libstdc++ is targeted and optimized
- for GCC/g++. This means that often libstdc++ uses specific,
- non-standard features of g++ that are not present in older
- versions of proprietary compilers. It may take as much as a year or two
- after an official release of GCC that contains these features for
- proprietary tools support these constructs.
- </p><p>
- In the near past, specific released versions of libstdc++ have
- been known to work with versions of the EDG C++ compiler, and
- vendor-specific proprietary C++ compilers such as the Intel ICC
- C++ compiler.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.solaris_long_long"></a><a id="q-solaris_long_long"></a><p><b>4.2.</b></p></td><td align="left" valign="top"><p>
- No 'long long' type on Solaris?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-solaris_long_long"></a></td><td align="left" valign="top"><p>
- By default we try to support the C99 <span class="type">long long</span> type.
- This requires that certain functions from your C library be present.
- </p><p>
- Up through release 3.0.2 the platform-specific tests performed by
- libstdc++ were too general, resulting in a conservative approach
- to enabling the <span class="type">long long</span> code paths. The most
- commonly reported platform affected was Solaris.
- </p><p>
- This has been fixed for libstdc++ releases greater than 3.0.3.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.predefined"></a><a id="q-predefined"></a><p><b>4.3.</b></p></td><td align="left" valign="top"><p>
- <code class="constant">_XOPEN_SOURCE</code> and <code class="constant">_GNU_SOURCE</code> are always defined?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-predefined"></a></td><td align="left" valign="top"><p>On Solaris, g++ (but not gcc) always defines the preprocessor
- macro <code class="constant">_XOPEN_SOURCE</code>. On GNU/Linux, the same happens
- with <code class="constant">_GNU_SOURCE</code>. (This is not an exhaustive list;
- other macros and other platforms are also affected.)
- </p><p>These macros are typically used in C library headers, guarding new
- versions of functions from their older versions. The C++ standard
- library includes the C standard library, but it requires the C90
- version, which for backwards-compatibility reasons is often not the
- default for many vendors.
- </p><p>More to the point, the C++ standard requires behavior which is only
- available on certain platforms after certain symbols are defined.
- Usually the issue involves I/O-related typedefs. In order to
- ensure correctness, the compiler simply predefines those symbols.
- </p><p>Note that it's not enough to #define them only when the library is
- being built (during installation). Since we don't have an 'export'
- keyword, much of the library exists as headers, which means that
- the symbols must also be defined as your programs are parsed and
- compiled.
- </p><p>To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in
- the gcc config headers for your target (and try changing them to
- see what happens when building complicated code). You can also run
- <span class="command"><strong>g++ -E -dM - &lt; /dev/null"</strong></span> to display
- a list of predefined macros for any particular installation.
- </p><p>This has been discussed on the mailing lists
- <a class="ulink" href="http://gcc.gnu.org/cgi-bin/htsearch?method=and&amp;format=builtin-long&amp;sort=score&amp;words=_XOPEN_SOURCE+Solaris" target="_top">quite a bit</a>.
- </p><p>This method is something of a wart. We'd like to find a cleaner
- solution, but nobody yet has contributed the time.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.darwin_ctype"></a><a id="q-darwin_ctype"></a><p><b>4.4.</b></p></td><td align="left" valign="top"><p>
- Mac OS X <code class="filename">ctype.h</code> is broken! How can I fix it?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-darwin_ctype"></a></td><td align="left" valign="top"><p>This is a long-standing bug in the OS X support. Fortunately,
- the patch is quite simple, and well-known.
- <a class="ulink" href="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html" target="_top"> Here's a
- link to the solution</a>.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.threads_i386"></a><a id="q-threads_i386"></a><p><b>4.5.</b></p></td><td align="left" valign="top"><p>
- Threading is broken on i386?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-threads_i386"></a></td><td align="left" valign="top"><p>
- </p><p>Support for atomic integer operations is/was broken on i386
- platforms. The assembly code accidentally used opcodes that are
- only available on the i486 and later. So if you configured GCC
- to target, for example, i386-linux, but actually used the programs
- on an i686, then you would encounter no problems. Only when
- actually running the code on a i386 will the problem appear.
- </p><p>This is fixed in 3.2.2.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.atomic_mips"></a><a id="q-atomic_mips"></a><p><b>4.6.</b></p></td><td align="left" valign="top"><p>
- MIPS atomic operations
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-atomic_mips"></a></td><td align="left" valign="top"><p>
- The atomic locking routines for MIPS targets requires MIPS II
- and later. A patch went in just after the 3.3 release to
- make mips* use the generic implementation instead. You can also
- configure for mipsel-elf as a workaround.
- </p><p>
- The mips*-*-linux* port continues to use the MIPS II routines, and more
- work in this area is expected.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.linux_glibc"></a><a id="q-linux_glibc"></a><p><b>4.7.</b></p></td><td align="left" valign="top"><p>
- Recent GNU/Linux glibc required?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-linux_glibc"></a></td><td align="left" valign="top"><p>When running on GNU/Linux, libstdc++ 3.2.1 (shared library version
- 5.0.1) and later uses localization and formatting code from the system
- C library (glibc) version 2.2.5. That version of glibc is over a
- year old and contains necessary bugfixes. Many GNU/Linux distros make
- glibc version 2.3.x available now.
- </p><p>The guideline is simple: the more recent the C++ library, the
- more recent the C library. (This is also documented in the main
- GCC installation instructions.)
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.freebsd_wchar"></a><a id="q-freebsd_wchar"></a><p><b>4.8.</b></p></td><td align="left" valign="top"><p>
- Can't use wchar_t/wstring on FreeBSD
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-freebsd_wchar"></a></td><td align="left" valign="top"><p>
- Older versions of FreeBSD's C library do not have sufficient
- support for wide character functions, and as a result the
- libstdc++ configury decides that wchar_t support should be
- disabled. In addition, the libstdc++ platform checks that
- enabled <span class="type">wchar_t</span> were quite strict, and not granular
- enough to detect when the minimal support to
- enable <span class="type">wchar_t</span> and C++ library structures
- like <code class="classname">wstring</code> were present. This impacted Solaris,
- Darwin, and BSD variants, and is fixed in libstdc++ versions post 4.1.0.
- </p><p>
- </p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.known_bugs"></a>5. Known Bugs</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>5.1. <a href="faq.html#faq.what_works">
- What works already?
- </a></dt><dt>5.2. <a href="faq.html#faq.standard_bugs">
- Bugs in the ISO C++ language or library specification
- </a></dt><dt>5.3. <a href="faq.html#faq.compiler_bugs">
- Bugs in the compiler (gcc/g++) and not libstdc++
- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_works"></a><a id="q-what_works"></a><p><b>5.1.</b></p></td><td align="left" valign="top"><p>
- What works already?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_works"></a></td><td align="left" valign="top"><p>
- Short answer: Pretty much everything <span class="emphasis"><em>works</em></span>
- except for some corner cases. Support for localization
- in <code class="classname">locale</code> may be incomplete on non-GNU
- platforms. Also dependant on the underlying platform is support
- for <span class="type">wchar_t</span> and <span class="type">long
- long</span> specializations, and details of thread support.
- </p><p>
- Long answer: See the implementation status pages for
- <a class="link" href="manual/status.html#manual.intro.status.standard.1998" title="C++ 1998/2003">C++98</a>,
- <a class="link" href="manual/status.html#manual.intro.status.standard.tr1" title="C++ TR1">TR1</a>, and
- <a class="link" href="manual/status.html#manual.intro.status.standard.200x" title="C++ 200x">C++0x</a>.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.standard_bugs"></a><a id="q-standard_bugs"></a><p><b>5.2.</b></p></td><td align="left" valign="top"><p>
- Bugs in the ISO C++ language or library specification
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-standard_bugs"></a></td><td align="left" valign="top"><p>
- Unfortunately, there are some.
- </p><p>
- For those people who are not part of the ISO Library Group
- (i.e., nearly all of us needing to read this page in the first
- place), a public list of the library defects is occasionally
- published <a class="ulink" href="http://anubis.dkuug.dk/jtc1/sc22/wg21/" target="_top">here</a>.
- Some of these issues have resulted in code changes in libstdc++.
- </p><p>
- If you think you've discovered a new bug that is not listed,
- please post a message describing your problem
- to <code class="email">&lt;<a class="email" href="mailto:libstdc++@gcc.gnu.org">libstdc++@gcc.gnu.org</a>&gt;</code> or the Usenet group
- comp.lang.c++.moderated.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.compiler_bugs"></a><a id="q-compiler_bugs"></a><p><b>5.3.</b></p></td><td align="left" valign="top"><p>
- Bugs in the compiler (gcc/g++) and not libstdc++
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-compiler_bugs"></a></td><td align="left" valign="top"><p>
- On occasion, the compiler is wrong. Please be advised that this
- happens much less often than one would think, and avoid jumping to
- conclusions.
- </p><p>
- First, examine the ISO C++ standard. Second, try another compiler
- or an older version of the GNU compilers. Third, you can find more
- information on the libstdc++ and the GCC mailing lists: search
- these lists with terms describing your issue.
- </p><p>
- Before reporting a bug, please examine the
- <a class="ulink" href="http://gcc.gnu.org/bugs.html" target="_top">bugs database</a> with the
- category set to “<span class="quote">g++</span>”.
- </p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.known_non-bugs"></a>6. Known Non-Bugs</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>6.1. <a href="faq.html#faq.stream_reopening_fails">
- Reopening a stream fails
- </a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose">
- -Weffc++ complains too much
- </a></dt><dt>6.3. <a href="faq.html#faq.ambiguous_overloads">
- Ambiguous overloads after including an old-style header
- </a></dt><dt>6.4. <a href="faq.html#faq.v2_headers">
- The g++-3 headers are not ours
- </a></dt><dt>6.5. <a href="faq.html#faq.boost_concept_checks">
- Errors about *Concept and
- constraints in the STL
- </a></dt><dt>6.6. <a href="faq.html#faq.dlopen_crash">
- Program crashes when using library code in a
- dynamically-loaded library
- </a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">
- “Memory leaks” in containers
- </a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">
- list::size() is O(n)!
- </a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
- Aw, that's easy to fix!
- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.stream_reopening_fails"></a><a id="q-stream_reopening_fails"></a><p><b>6.1.</b></p></td><td align="left" valign="top"><p>
- Reopening a stream fails
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-stream_reopening_fails"></a></td><td align="left" valign="top"><p>
- One of the most-reported non-bug reports. Executing a sequence like:
- </p><div class="literallayout"><p><br />
-    #include &lt;fstream&gt;<br />
-    ...<br />
-    std::fstream  fs(“<span class="quote">a_file</span>”);<br />
-    // .<br />
-    // . do things with fs...<br />
-    // .<br />
-    fs.close();<br />
-    fs.open(“<span class="quote">a_new_file</span>”);<br />
-    </p></div><p>
- All operations on the re-opened <code class="varname">fs</code> will fail, or at
- least act very strangely. Yes, they often will, especially if
- <code class="varname">fs</code> reached the EOF state on the previous file. The
- reason is that the state flags are <span class="emphasis"><em>not</em></span> cleared
- on a successful call to open(). The standard unfortunately did
- not specify behavior in this case, and to everybody's great sorrow,
- the <a class="link" href="manual/bugs.html" title="Bugs">proposed LWG resolution in
- DR #22</a> is to leave the flags unchanged. You must insert a call
- to <code class="function">fs.clear()</code> between the calls to close() and open(),
- and then everything will work like we all expect it to work.
- <span class="emphasis"><em>Update:</em></span> for GCC 4.0 we implemented the resolution
- of <a class="link" href="manual/bugs.html" title="Bugs">DR #409</a> and open()
- now calls <code class="function">clear()</code> on success!
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.wefcxx_verbose"></a><a id="q-wefcxx_verbose"></a><p><b>6.2.</b></p></td><td align="left" valign="top"><p>
- -Weffc++ complains too much
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-wefcxx_verbose"></a></td><td align="left" valign="top"><p>
- Many warnings are emitted when <code class="literal">-Weffc++</code> is used. Making
- libstdc++ <code class="literal">-Weffc++</code>-clean is not a goal of the project,
- for a few reasons. Mainly, that option tries to enforce
- object-oriented programming, while the Standard Library isn't
- necessarily trying to be OO.
- </p><p>
- We do, however, try to have libstdc++ sources as clean as possible. If
- you see some simple changes that pacify <code class="literal">-Weffc++</code>
- without other drawbacks, send us a patch.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.ambiguous_overloads"></a><a id="q-ambiguous_overloads"></a><p><b>6.3.</b></p></td><td align="left" valign="top"><p>
- Ambiguous overloads after including an old-style header
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-ambiguous_overloads"></a></td><td align="left" valign="top"><p>
- Another problem is the <code class="literal">rel_ops</code> namespace and the template
- comparison operator functions contained therein. If they become
- visible in the same namespace as other comparison functions
- (e.g., “<span class="quote">using</span>” them and the &lt;iterator&gt; header),
- then you will suddenly be faced with huge numbers of ambiguity
- errors. This was discussed on the -v3 list; Nathan Myers
- <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html" target="_top">sums
- things up here</a>. The collisions with vector/string iterator
- types have been fixed for 3.1.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.v2_headers"></a><a id="q-v2_headers"></a><p><b>6.4.</b></p></td><td align="left" valign="top"><p>
- The g++-3 headers are <span class="emphasis"><em>not ours</em></span>
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-v2_headers"></a></td><td align="left" valign="top"><p>
- If you have found an extremely broken header file which is
- causing problems for you, look carefully before submitting a
- "high" priority bug report (which you probably
- shouldn't do anyhow; see the last paragraph of the page
- describing <a class="ulink" href="http://gcc.gnu.org/bugs.html" target="_top">the GCC
- bug database</a>).
- </p><p>
- If the headers are in <code class="filename">${prefix}/include/g++-3</code>, or
- if the installed library's name looks like
- <code class="filename">libstdc++-2.10.a</code> or
- <code class="filename">libstdc++-libc6-2.10.so</code>, then you are using the
- old libstdc++-v2 library, which is nonstandard and
- unmaintained. Do not report problems with -v2 to the -v3
- mailing list.
- </p><p>
- For GCC versions 3.0 and 3.1 the libstdc++ header files are
- installed in <code class="filename">${prefix}/include/g++-v3</code> (see the
- 'v'?). Starting with version 3.2 the headers are installed in
- <code class="filename">${prefix}/include/c++/${version}</code> as this prevents
- headers from previous versions being found by mistake.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.boost_concept_checks"></a><a id="q-boost_concept_checks"></a><p><b>6.5.</b></p></td><td align="left" valign="top"><p>
- Errors about <span class="emphasis"><em>*Concept</em></span> and
- <span class="emphasis"><em>constraints</em></span> in the STL
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-boost_concept_checks"></a></td><td align="left" valign="top"><p>
- If you see compilation errors containing messages about
- <span class="errortext">foo Concept </span>and something to do with a
- <span class="errortext">constraints</span> member function, then most
- likely you have violated one of the requirements for types used
- during instantiation of template containers and functions. For
- example, EqualityComparableConcept appears if your types must be
- comparable with == and you have not provided this capability (a
- typo, or wrong visibility, or you just plain forgot, etc).
- </p><p>
- More information, including how to optionally enable/disable the
- checks, is available
- <a class="link" href="manual/bk01pt03ch08.html" title="Chapter 8. Concept Checking">here</a>.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.dlopen_crash"></a><a id="q-dlopen_crash"></a><p><b>6.6.</b></p></td><td align="left" valign="top"><p>
- Program crashes when using library code in a
- dynamically-loaded library
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-dlopen_crash"></a></td><td align="left" valign="top"><p>
- If you are using the C++ library across dynamically-loaded
- objects, make certain that you are passing the correct options
- when compiling and linking:
- </p><div class="literallayout"><p><br />
-    // compile your library components<br />
-    g++ -fPIC -c a.cc<br />
-    g++ -fPIC -c b.cc<br />
-    ...<br />
-    g++ -fPIC -c z.cc<br />
-<br />
-    // create your library<br />
-    g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o<br />
-<br />
-    // link the executable<br />
-    g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl<br />
-    </p></div></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.memory_leaks"></a><a id="q-memory_leaks"></a><p><b>6.7.</b></p></td><td align="left" valign="top"><p>
- “<span class="quote">Memory leaks</span>” in containers
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"></a></td><td align="left" valign="top"><p>
- A few people have reported that the standard containers appear
- to leak memory when tested with memory checkers such as
- <a class="ulink" href="http://valgrind.org/" target="_top">valgrind</a>.
- The library's default allocators keep free memory in a pool
- for later reuse, rather than returning it to the OS. Although
- this memory is always reachable by the library and is never
- lost, memory debugging tools can report it as a leak. If you
- want to test the library for memory leaks please read
- <a class="link" href="manual/debug.html#debug.memory" title="Memory Leak Hunting">Tips for memory leak hunting</a>
- first.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.list_size_on"></a><a id="q-list_size_on"></a><p><b>6.8.</b></p></td><td align="left" valign="top"><p>
- list::size() is O(n)!
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-list_size_on"></a></td><td align="left" valign="top"><p>
- See
- the <a class="link" href="manual/containers.html" title="Part VII.  Containers">Containers</a>
- chapter.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.easy_to_fix"></a><a id="q-easy_to_fix"></a><p><b>6.9.</b></p></td><td align="left" valign="top"><p>
- Aw, that's easy to fix!
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-easy_to_fix"></a></td><td align="left" valign="top"><p>
- If you have found a bug in the library and you think you have
- a working fix, then send it in! The main GCC site has a page
- on <a class="ulink" href="http://gcc.gnu.org/contribute.html" target="_top">submitting
- patches</a> that covers the procedure, but for libstdc++ you
- should also send the patch to our mailing list in addition to
- the GCC patches mailing list. The libstdc++
- <a class="link" href="manual/appendix_contributing.html" title="Appendix A.  Contributing">contributors' page</a>
- also talks about how to submit patches.
- </p><p>
- In addition to the description, the patch, and the ChangeLog
- entry, it is a Good Thing if you can additionally create a small
- test program to test for the presence of the bug that your
- patch fixes. Bugs have a way of being reintroduced; if an old
- bug creeps back in, it will be caught immediately by the
- <a class="ulink" href="#2_4" target="_top">testsuite</a> -- but only if such a test exists.
- </p></td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.misc"></a>7. Miscellaneous</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>7.1. <a href="faq.html#faq.iterator_as_pod">
- string::iterator is not char*; vector&lt;T&gt;::iterator is not T*
- </a></dt><dt>7.2. <a href="faq.html#faq.what_is_next">
- What's next after libstdc++?
- </a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl">
- What about the STL from SGI?
- </a></dt><dt>7.4. <a href="faq.html#faq.extensions_and_backwards_compat">
- Extensions and Backward Compatibility
- </a></dt><dt>7.5. <a href="faq.html#faq.tr1_support">
- Does libstdc++ support TR1?
- </a></dt><dt>7.6. <a href="faq.html#faq.get_iso_cxx">How do I get a copy of the ISO C++ Standard?
- </a></dt><dt>7.7. <a href="faq.html#faq.what_is_abi">
- What's an ABI and why is it so messy?
- </a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity">
- How do I make std::vector&lt;T&gt;::capacity() == std::vector&lt;T&gt;::size?
- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.iterator_as_pod"></a><a id="faq.iterator_as_pod_q"></a><p><b>7.1.</b></p></td><td align="left" valign="top"><p>
- string::iterator is not char*; vector&lt;T&gt;::iterator is not T*
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.iterator_as_pod_a"></a></td><td align="left" valign="top"><p>
- If you have code that depends on container&lt;T&gt; iterators
- being implemented as pointer-to-T, your code is broken. It's
- considered a feature, not a bug, that libstdc++ points this out.
- </p><p>
- While there are arguments for iterators to be implemented in
- that manner, A) they aren't very good ones in the long term,
- and B) they were never guaranteed by the Standard anyway. The
- type-safety achieved by making iterators a real class rather
- than a typedef for <span class="type">T*</span> outweighs nearly all opposing
- arguments.
- </p><p>
- Code which does assume that a vector iterator <code class="varname">i</code>
- is a pointer can often be fixed by changing <code class="varname">i</code> in
- certain expressions to <code class="varname">&amp;*i</code>. Future revisions
- of the Standard are expected to bless this usage for
- vector&lt;&gt; (but not for basic_string&lt;&gt;).
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_next"></a><a id="q-what_is_next"></a><p><b>7.2.</b></p></td><td align="left" valign="top"><p>
- What's next after libstdc++?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_next"></a></td><td align="left" valign="top"><p>
- Hopefully, not much. The goal of libstdc++ is to produce a
- fully-compliant, fully-portable Standard Library. After that,
- we're mostly done: there won't <span class="emphasis"><em>be</em></span> any
- more compliance work to do.
- </p><p>
- There is an effort underway to add significant extensions to
- the standard library specification. The latest version of
- this effort is described in
- <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf" target="_top">
- The C++ Library Technical Report 1</a>.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.sgi_stl"></a><a id="q-sgi_stl"></a><p><b>7.3.</b></p></td><td align="left" valign="top"><p>
- What about the STL from SGI?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-sgi_stl"></a></td><td align="left" valign="top"><p>
- The <a class="ulink" href="http://www.sgi.com/tech/stl/" target="_top">STL from SGI</a>,
- version 3.3, was the final merge of the STL codebase. The
- code in libstdc++ contains many fixes and changes, and
- the SGI code is no longer under active
- development. We expect that no future merges will take place.
- </p><p>
- In particular, <code class="classname">string</code> is not from SGI and makes no
- use of their "rope" class (which is included as an
- optional extension), nor is <code class="classname">valarray</code> and some others.
- Classes like <code class="classname">vector&lt;&gt;</code> are, but have been
- extensively modified.
- </p><p>
- More information on the evolution of libstdc++ can be found at the
- <a class="link" href="manual/api.html" title="API Evolution and Deprecation History">API
- evolution</a>
- and <a class="link" href="manual/backwards.html" title="Backwards Compatibility">backwards
- compatibility</a> documentation.
- </p><p>
- The FAQ for SGI's STL (one jump off of their main page) is
- still recommended reading.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.extensions_and_backwards_compat"></a><a id="q-extensions_and_backwards_compat"></a><p><b>7.4.</b></p></td><td align="left" valign="top"><p>
- Extensions and Backward Compatibility
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-extensions_and_backwards_compat"></a></td><td align="left" valign="top"><p>
- See the <a class="link" href="manual/backwards.html" title="Backwards Compatibility">link</a> on backwards compatibility and <a class="link" href="manual/api.html" title="API Evolution and Deprecation History">link</a> on evolution.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.tr1_support"></a><a id="q-tr1_support"></a><p><b>7.5.</b></p></td><td align="left" valign="top"><p>
- Does libstdc++ support TR1?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-tr1_support"></a></td><td align="left" valign="top"><p>
- Yes.
- </p><p>
- The C++ Standard Library Technical Report adds many new features to
- the library. The latest version of this effort is described in
- <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf" target="_top">
- Technical Report 1</a>.
- </p><p>
- The implementation status of TR1 in libstdc++ can be tracked <a class="link" href="manual/status.html#manual.intro.status.standard.tr1" title="C++ TR1">on the TR1 status
- page</a>.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.get_iso_cxx"></a><a id="q-get_iso_cxx"></a><p><b>7.6.</b></p></td><td align="left" valign="top"><p>How do I get a copy of the ISO C++ Standard?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-get_iso_cxx"></a></td><td align="left" valign="top"><p>
- Copies of the full ISO 14882 standard are available on line via
- the ISO mirror site for committee members. Non-members, or those
- who have not paid for the privilege of sitting on the committee
- and sustained their two-meeting commitment for voting rights, may
- get a copy of the standard from their respective national
- standards organization. In the USA, this national standards
- organization is ANSI and their website is
- right <a class="ulink" href="http://www.ansi.org" target="_top">here</a>. (And if
- you've already registered with them, clicking this link will take
- you to directly to the place where you can
- <a class="ulink" href="http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%3A2003" target="_top">buy the standard on-line</a>.
- </p><p>
- Who is your country's member body? Visit the
- <a class="ulink" href="http://www.iso.ch/" target="_top">ISO homepage</a> and find out!
- </p><p>
- The 2003 version of the standard (the 1998 version plus TC1) is
- available in print, ISBN 0-470-84674-7.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_abi"></a><a id="q-what_is_abi"></a><p><b>7.7.</b></p></td><td align="left" valign="top"><p>
- What's an ABI and why is it so messy?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_abi"></a></td><td align="left" valign="top"><p>
- <acronym class="acronym">ABI</acronym> stands for “<span class="quote">Application Binary
- Interface</span>”. Conventionally, it refers to a great
- mass of details about how arguments are arranged on the call
- stack and/or in registers, and how various types are arranged
- and padded in structs. A single CPU design may suffer
- multiple ABIs designed by different development tool vendors
- who made different choices, or even by the same vendor for
- different target applications or compiler versions. In ideal
- circumstances the CPU designer presents one ABI and all the
- OSes and compilers use it. In practice every ABI omits
- details that compiler implementers (consciously or
- accidentally) must choose for themselves.
- </p><p>
- That ABI definition suffices for compilers to generate code so a
- program can interact safely with an OS and its lowest-level libraries.
- Users usually want an ABI to encompass more detail, allowing libraries
- built with different compilers (or different releases of the same
- compiler!) to be linked together. For C++, this includes many more
- details than for C, and CPU designers (for good reasons elaborated
- below) have not stepped up to publish C++ ABIs. The details include
- virtual function implementation, struct inheritance layout, name
- mangling, and exception handling. Such an ABI has been defined for
- GNU C++, and is immediately useful for embedded work relying only on
- a “<span class="quote">free-standing implementation</span>” that doesn't include (much
- of) the standard library. It is a good basis for the work to come.
- </p><p>
- A useful C++ ABI must also incorporate many details of the standard
- library implementation. For a C ABI, the layouts of a few structs
- (such as FILE, stat, jmpbuf, and the like) and a few macros suffice.
- For C++, the details include the complete set of names of functions
- and types used, the offsets of class members and virtual functions,
- and the actual definitions of all inlines. C++ exposes many more
- library details to the caller than C does. It makes defining
- a complete ABI a much bigger undertaking, and requires not just
- documenting library implementation details, but carefully designing
- those details so that future bug fixes and optimizations don't
- force breaking the ABI.
- </p><p>
- There are ways to help isolate library implementation details from the
- ABI, but they trade off against speed. Library details used in
- inner loops (e.g., getchar) must be exposed and frozen for all
- time, but many others may reasonably be kept hidden from user code,
- so they may later be changed. Deciding which, and implementing
- the decisions, must happen before you can reasonably document a
- candidate C++ ABI that encompasses the standard library.
- </p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.size_equals_capacity"></a><a id="q-size_equals_capacity"></a><p><b>7.8.</b></p></td><td align="left" valign="top"><p>
- How do I make std::vector&lt;T&gt;::capacity() == std::vector&lt;T&gt;::size?
- </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size_equals_capacity"></a></td><td align="left" valign="top"><p>
- The standard idiom for deallocating a <code class="classname">vector&lt;T&gt;</code>'s
- unused memory is to create a temporary copy of the vector and swap their
- contents, e.g. for <code class="classname">vector&lt;T&gt; v</code>
- </p><div class="literallayout"><p><br />
-     std::vector&lt;T&gt;(v).swap(v);<br />
-    </p></div><p>
- The copy will take O(n) time and the swap is constant time.
- </p><p>
- See <a class="link" href="manual/bk01pt05ch13s05.html" title="Shrink to Fit">Shrink-to-fit
- strings</a> for a similar solution for strings.
- </p></td></tr></tbody></table></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk03.html">Up</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="spine.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/index.html b/gcc-4.4.3/libstdc++-v3/doc/html/index.html
deleted file mode 100644
index 96ff103fb..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/index.html
+++ /dev/null
@@ -1,43 +0,0 @@
-<html>
-
-<head>
-<title>The GNU C++ Library Documentation</title>
-</head>
-
-<body>
-
-<!-- ==================================================================== -->
-
-
-<div>
-<h1>The GNU C++ Library Documentation</h1>
-
-<p>Copyright 2008 FSF</p>
-
-<p>
- Permission is granted to copy, distribute and/or modify this
- document under the terms of the GNU Free Documentation
- License, Version 1.2 or any later version published by the
- Free Software Foundation; with no Invariant Sections, with no
- Front-Cover Texts, and with no Back-Cover Texts.
-</p>
-<p>
- This is the top level of the libstdc++ documentation tree.
- The documentation is contained in three logically separate
- documents, as listed in the following Table of Contents.
-</p>
-</div>
-
-<div>
-<p><b>Table of Contents</b></p>
-<dl>
-<dt><a href="manual/spine.html">Manual</a></dt>
-<dt><a href="faq.html">Frequently Asked Questions</a></dt>
-<dt><a href="api.html">API and Source Documentation</a></dt>
-</dl>
-</div>
-
-</body>
-</html>
-
-
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/abi.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/abi.html
deleted file mode 100644
index 71fe6c05c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/abi.html
+++ /dev/null
@@ -1,521 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>ABI Policy and Guidelines</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; C++&#10; , &#10; ABI&#10; , &#10; version&#10; , &#10; dynamic&#10; , &#10; shared&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_porting.html" title="Appendix B.  Porting and Maintenance" /><link rel="prev" href="internals.html" title="Porting to New Hardware or Operating Systems" /><link rel="next" href="api.html" title="API Evolution and Deprecation History" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">ABI Policy and Guidelines</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="internals.html">Prev</a> </td><th width="60%" align="center">Appendix B. 
- Porting and Maintenance
-
-</th><td width="20%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="appendix.porting.abi"></a>ABI Policy and Guidelines</h2></div></div></div><p>
-</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.cxx_interface"></a>The C++ Interface</h3></div></div></div><p>
- C++ applications often dependent on specific language support
- routines, say for throwing exceptions, or catching exceptions, and
- perhaps also dependent on features in the C++ Standard Library.
-</p><p>
- The C++ Standard Library has many include files, types defined in
- those include files, specific named functions, and other
- behavior. The text of these behaviors, as written in source include
- files, is called the Application Programing Interface, or API.
-</p><p>
- Furthermore, C++ source that is compiled into object files is
- transformed by the compiler: it arranges objects with specific
- alignment and in a particular layout, mangling names according to a
- well-defined algorithm, has specific arrangements for the support of
- virtual functions, etc. These details are defined as the compiler
- Application Binary Interface, or ABI. The GNU C++ compiler uses an
- industry-standard C++ ABI starting with version 3. Details can be
- found in the <a class="ulink" href="http://www.codesourcery.com/cxx-abi/abi.html" target="_top"> ABI
- specification</a>.
-</p><p>
- The GNU C++ compiler, g++, has a compiler command line option to
- switch between various different C++ ABIs. This explicit version
- switch is the flag <code class="code">-fabi-version</code>. In addition, some
- g++ command line options may change the ABI as a side-effect of
- use. Such flags include <code class="code">-fpack-struct</code> and
- <code class="code">-fno-exceptions</code>, but include others: see the complete
- list in the GCC manual under the heading <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code%20Gen%20Options" target="_top">Options
- for Code Generation Conventions</a>.
-</p><p>
- The configure options used when building a specific libstdc++
- version may also impact the resulting library ABI. The available
- configure options, and their impact on the library ABI, are
- documented
-<a class="link" href="configure.html" title="Configure">here</a>.
-</p><p> Putting all of these ideas together results in the C++ Standard
-library ABI, which is the compilation of a given library API by a
-given compiler ABI. In a nutshell:
-</p><p>
- “<span class="quote">
- library API + compiler ABI = library ABI
- </span>”
-</p><p>
- The library ABI is mostly of interest for end-users who have
- unresolved symbols and are linking dynamically to the C++ Standard
- library, and who thus must be careful to compile their application
- with a compiler that is compatible with the available C++ Standard
- library binary. In this case, compatible is defined with the equation
- above: given an application compiled with a given compiler ABI and
- library API, it will work correctly with a Standard C++ Library
- created with the same constraints.
-</p><p>
- To use a specific version of the C++ ABI, one must use a
- corresponding GNU C++ toolchain (i.e., g++ and libstdc++) that
- implements the C++ ABI in question.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.versioning"></a>Versioning</h3></div></div></div><p> The C++ interface has evolved throughout the history of the GNU
-C++ toolchain. With each release, various details have been changed so
-as to give distinct versions to the C++ interface.
-</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.goals"></a>Goals</h4></div></div></div><p>Extending existing, stable ABIs. Versioning gives subsequent
-releases of library binaries the ability to add new symbols and add
-functionality, all the while retaining compatibility with the previous
-releases in the series. Thus, program binaries linked with the initial
-release of a library binary will still link correctly if the library
-binary is replaced by carefully-managed subsequent library
-binaries. This is called forward compatibility.
-</p><p>
-The reverse (backwards compatibility) is not true. It is not possible
-to take program binaries linked with the latest version of a library
-binary in a release series (with additional symbols added), substitute
-in the initial release of the library binary, and remain link
-compatible.
-</p><p>Allows multiple, incompatible ABIs to coexist at the same time.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.history"></a>History</h4></div></div></div><p>
- How can this complexity be managed? What does C++ versioning mean?
- Because library and compiler changes often make binaries compiled
- with one version of the GNU tools incompatible with binaries
- compiled with other (either newer or older) versions of the same GNU
- tools, specific techniques are used to make managing this complexity
- easier.
-</p><p>
- The following techniques are used:
-</p><div class="orderedlist"><ol type="1"><li><p>Release versioning on the libgcc_s.so binary. </p><p>This is implemented via file names and the ELF
- <code class="constant">DT_SONAME</code> mechanism (at least on ELF
- systems). It is versioned as follows:
- </p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: libgcc_s.so.1</p></li><li><p>gcc-3.0.1: libgcc_s.so.1</p></li><li><p>gcc-3.0.2: libgcc_s.so.1</p></li><li><p>gcc-3.0.3: libgcc_s.so.1</p></li><li><p>gcc-3.0.4: libgcc_s.so.1</p></li><li><p>gcc-3.1.0: libgcc_s.so.1</p></li><li><p>gcc-3.1.1: libgcc_s.so.1</p></li><li><p>gcc-3.2.0: libgcc_s.so.1</p></li><li><p>gcc-3.2.1: libgcc_s.so.1</p></li><li><p>gcc-3.2.2: libgcc_s.so.1</p></li><li><p>gcc-3.2.3: libgcc_s.so.1</p></li><li><p>gcc-3.3.0: libgcc_s.so.1</p></li><li><p>gcc-3.3.1: libgcc_s.so.1</p></li><li><p>gcc-3.3.2: libgcc_s.so.1</p></li><li><p>gcc-3.3.3: libgcc_s.so.1</p></li><li><p>gcc-3.4.x, gcc-4.[0-3].x: on m68k-linux and
- hppa-linux this is either libgcc_s.so.1 (when configuring
- <code class="code">--with-sjlj-exceptions</code>) or libgcc_s.so.2. For all
- others, this is libgcc_s.so.1. </p></li></ul></div></li><li><p>Symbol versioning on the libgcc_s.so binary.</p><p>It is versioned with the following labels and version
- definitions, where the version definition is the maximum for a
- particular release. Labels are cumulative. If a particular release
- is not listed, it has the same version labels as the preceding
- release.</p><p>This corresponds to the mapfile: gcc/libgcc-std.ver</p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: GCC_3.0</p></li><li><p>gcc-3.3.0: GCC_3.3</p></li><li><p>gcc-3.3.1: GCC_3.3.1</p></li><li><p>gcc-3.3.2: GCC_3.3.2</p></li><li><p>gcc-3.3.4: GCC_3.3.4</p></li><li><p>gcc-3.4.0: GCC_3.4</p></li><li><p>gcc-3.4.2: GCC_3.4.2</p></li><li><p>gcc-3.4.4: GCC_3.4.4</p></li><li><p>gcc-4.0.0: GCC_4.0.0</p></li><li><p>gcc-4.1.0: GCC_4.1.0</p></li><li><p>gcc-4.2.0: GCC_4.2.0</p></li><li><p>gcc-4.3.0: GCC_4.3.0</p></li></ul></div></li><li><p>
- Release versioning on the libstdc++.so binary, implemented in
- the same was as the libgcc_s.so binary above. Listed is the
- filename: <code class="constant">DT_SONAME</code> can be deduced from
- the filename by removing the last two period-delimited numbers. For
- example, filename <code class="filename">libstdc++.so.5.0.4</code>
- corresponds to a <code class="constant">DT_SONAME</code> of
- <code class="constant">libstdc++.so.5</code>. Binaries with equivalent
- <code class="constant">DT_SONAME</code>s are forward-compatibile: in
- the table below, releases incompatible with the previous
- one are explicitly noted.
- </p><p>It is versioned as follows:
- </p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: libstdc++.so.3.0.0</p></li><li><p>gcc-3.0.1: libstdc++.so.3.0.1</p></li><li><p>gcc-3.0.2: libstdc++.so.3.0.2</p></li><li><p>gcc-3.0.3: libstdc++.so.3.0.2 (See Note 1)</p></li><li><p>gcc-3.0.4: libstdc++.so.3.0.4</p></li><li><p>gcc-3.1.0: libstdc++.so.4.0.0 <span class="emphasis"><em>(Incompatible with previous)</em></span></p></li><li><p>gcc-3.1.1: libstdc++.so.4.0.1</p></li><li><p>gcc-3.2.0: libstdc++.so.5.0.0 <span class="emphasis"><em>(Incompatible with previous)</em></span></p></li><li><p>gcc-3.2.1: libstdc++.so.5.0.1</p></li><li><p>gcc-3.2.2: libstdc++.so.5.0.2</p></li><li><p>gcc-3.2.3: libstdc++.so.5.0.3 (See Note 2)</p></li><li><p>gcc-3.3.0: libstdc++.so.5.0.4</p></li><li><p>gcc-3.3.1: libstdc++.so.5.0.5</p></li><li><p>gcc-3.3.2: libstdc++.so.5.0.5</p></li><li><p>gcc-3.3.3: libstdc++.so.5.0.5</p></li><li><p>gcc-3.4.0: libstdc++.so.6.0.0 <span class="emphasis"><em>(Incompatible with previous)</em></span></p></li><li><p>gcc-3.4.1: libstdc++.so.6.0.1</p></li><li><p>gcc-3.4.2: libstdc++.so.6.0.2</p></li><li><p>gcc-3.4.3: libstdc++.so.6.0.3</p></li><li><p>gcc-3.4.4: libstdc++.so.6.0.3</p></li><li><p>gcc-3.4.5: libstdc++.so.6.0.3</p></li><li><p>gcc-3.4.6: libstdc++.so.6.0.3</p></li><li><p>gcc-4.0.0: libstdc++.so.6.0.4</p></li><li><p>gcc-4.0.1: libstdc++.so.6.0.5</p></li><li><p>gcc-4.0.2: libstdc++.so.6.0.6</p></li><li><p>gcc-4.0.3: libstdc++.so.6.0.7</p></li><li><p>gcc-4.1.0: libstdc++.so.6.0.7</p></li><li><p>gcc-4.1.1: libstdc++.so.6.0.8</p></li><li><p>gcc-4.1.2: libstdc++.so.6.0.8</p></li><li><p>gcc-4.2.0: libstdc++.so.6.0.9</p></li><li><p>gcc-4.2.1: libstdc++.so.6.0.9 (See Note 3)</p></li><li><p>gcc-4.2.2: libstdc++.so.6.0.9</p></li><li><p>gcc-4.2.3: libstdc++.so.6.0.9</p></li><li><p>gcc-4.2.4: libstdc++.so.6.0.9</p></li><li><p>gcc-4.3.0: libstdc++.so.6.0.10</p></li><li><p>gcc-4.3.1: libstdc++.so.6.0.10</p></li><li><p>gcc-4.3.2: libstdc++.so.6.0.10</p></li></ul></div><p>
- Note 1: Error should be libstdc++.so.3.0.3.
- </p><p>
- Note 2: Not strictly required.
- </p><p>
- Note 3: This release (but not previous or subsequent) has one
- known incompatibility, see <a class="ulink" href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33678" target="_top">33678</a>
- in the GCC bug database.
- </p></li><li><p>Symbol versioning on the libstdc++.so binary.</p><p>mapfile: libstdc++/config/linker-map.gnu</p><p>It is versioned with the following labels and version
- definitions, where the version definition is the maximum for a
- particular release. Note, only symbol which are newly introduced
- will use the maximum version definition. Thus, for release series
- with the same label, but incremented version definitions, the later
- release has both versions. (An example of this would be the
- gcc-3.2.1 release, which has GLIBCPP_3.2.1 for new symbols and
- GLIBCPP_3.2 for symbols that were introduced in the gcc-3.2.0
- release.) If a particular release is not listed, it has the same
- version labels as the preceding release.
- </p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: (Error, not versioned)</p></li><li><p>gcc-3.0.1: (Error, not versioned)</p></li><li><p>gcc-3.0.2: (Error, not versioned)</p></li><li><p>gcc-3.0.3: (Error, not versioned)</p></li><li><p>gcc-3.0.4: (Error, not versioned)</p></li><li><p>gcc-3.1.0: GLIBCPP_3.1, CXXABI_1</p></li><li><p>gcc-3.1.1: GLIBCPP_3.1, CXXABI_1</p></li><li><p>gcc-3.2.0: GLIBCPP_3.2, CXXABI_1.2</p></li><li><p>gcc-3.2.1: GLIBCPP_3.2.1, CXXABI_1.2</p></li><li><p>gcc-3.2.2: GLIBCPP_3.2.2, CXXABI_1.2</p></li><li><p>gcc-3.2.3: GLIBCPP_3.2.2, CXXABI_1.2</p></li><li><p>gcc-3.3.0: GLIBCPP_3.2.2, CXXABI_1.2.1</p></li><li><p>gcc-3.3.1: GLIBCPP_3.2.3, CXXABI_1.2.1</p></li><li><p>gcc-3.3.2: GLIBCPP_3.2.3, CXXABI_1.2.1</p></li><li><p>gcc-3.3.3: GLIBCPP_3.2.3, CXXABI_1.2.1</p></li><li><p>gcc-3.4.0: GLIBCXX_3.4, CXXABI_1.3</p></li><li><p>gcc-3.4.1: GLIBCXX_3.4.1, CXXABI_1.3</p></li><li><p>gcc-3.4.2: GLIBCXX_3.4.2</p></li><li><p>gcc-3.4.3: GLIBCXX_3.4.3</p></li><li><p>gcc-4.0.0: GLIBCXX_3.4.4, CXXABI_1.3.1</p></li><li><p>gcc-4.0.1: GLIBCXX_3.4.5</p></li><li><p>gcc-4.0.2: GLIBCXX_3.4.6</p></li><li><p>gcc-4.0.3: GLIBCXX_3.4.7</p></li><li><p>gcc-4.1.1: GLIBCXX_3.4.8</p></li><li><p>gcc-4.2.0: GLIBCXX_3.4.9</p></li><li><p>gcc-4.3.0: GLIBCXX_3.4.10, CXXABI_1.3.2</p></li></ul></div></li><li><p>Incremental bumping of a compiler pre-defined macro,
- __GXX_ABI_VERSION. This macro is defined as the version of the
- compiler v3 ABI, with g++ 3.0.x being version 100. This macro will
- be automatically defined whenever g++ is used (the curious can
- test this by invoking g++ with the '-v' flag.)
- </p><p>
- This macro was defined in the file "lang-specs.h" in the gcc/cp directory.
- Later versions defined it in "c-common.c" in the gcc directory, and from
- G++ 3.4 it is defined in c-cppbuiltin.c and its value determined by the
- '-fabi-version' command line option.
- </p><p>
- It is versioned as follows, where 'n' is given by '-fabi-version=n':
- </p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.x: 100</p></li><li><p>gcc-3.1.x: 100 (Error, should be 101)</p></li><li><p>gcc-3.2.x: 102</p></li><li><p>gcc-3.3.x: 102</p></li><li><p>gcc-3.4.x, gcc-4.[0-3].x: 102 (when n=1)</p></li><li><p>gcc-3.4.x, gcc-4.[0-3].x: 1000 + n (when n&gt;1) </p></li><li><p>gcc-3.4.x, gcc-4.[0-3].x: 999999 (when n=0)</p></li></ul></div><p></p></li><li><p>Changes to the default compiler option for
- <code class="code">-fabi-version</code>.
- </p><p>
- It is versioned as follows:
- </p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.x: (Error, not versioned) </p></li><li><p>gcc-3.1.x: (Error, not versioned) </p></li><li><p>gcc-3.2.x: <code class="code">-fabi-version=1</code></p></li><li><p>gcc-3.3.x: <code class="code">-fabi-version=1</code></p></li><li><p>gcc-3.4.x, gcc-4.[0-3].x: <code class="code">-fabi-version=2</code> <span class="emphasis"><em>(Incompatible with previous)</em></span></p></li></ul></div><p></p></li><li><p>Incremental bumping of a library pre-defined macro. For releases
- before 3.4.0, the macro is __GLIBCPP__. For later releases, it's
- __GLIBCXX__. (The libstdc++ project generously changed from CPP to
- CXX throughout its source to allow the "C" pre-processor the CPP
- macro namespace.) These macros are defined as the date the library
- was released, in compressed ISO date format, as an unsigned long.
- </p><p>
- This macro is defined in the file "c++config" in the
- "libstdc++/include/bits" directory. (Up to gcc-4.1.0, it was
- changed every night by an automated script. Since gcc-4.1.0, it is
- the same value as gcc/DATESTAMP.)
- </p><p>
- It is versioned as follows:
- </p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: 20010615</p></li><li><p>gcc-3.0.1: 20010819</p></li><li><p>gcc-3.0.2: 20011023</p></li><li><p>gcc-3.0.3: 20011220</p></li><li><p>gcc-3.0.4: 20020220</p></li><li><p>gcc-3.1.0: 20020514</p></li><li><p>gcc-3.1.1: 20020725</p></li><li><p>gcc-3.2.0: 20020814</p></li><li><p>gcc-3.2.1: 20021119</p></li><li><p>gcc-3.2.2: 20030205</p></li><li><p>gcc-3.2.3: 20030422</p></li><li><p>gcc-3.3.0: 20030513</p></li><li><p>gcc-3.3.1: 20030804</p></li><li><p>gcc-3.3.2: 20031016</p></li><li><p>gcc-3.3.3: 20040214</p></li><li><p>gcc-3.4.0: 20040419</p></li><li><p>gcc-3.4.1: 20040701</p></li><li><p>gcc-3.4.2: 20040906</p></li><li><p>gcc-3.4.3: 20041105</p></li><li><p>gcc-3.4.4: 20050519</p></li><li><p>gcc-3.4.5: 20051201</p></li><li><p>gcc-3.4.6: 20060306</p></li><li><p>gcc-4.0.0: 20050421</p></li><li><p>gcc-4.0.1: 20050707</p></li><li><p>gcc-4.0.2: 20050921</p></li><li><p>gcc-4.0.3: 20060309</p></li><li><p>gcc-4.1.0: 20060228</p></li><li><p>gcc-4.1.1: 20060524</p></li><li><p>gcc-4.1.2: 20070214</p></li><li><p>gcc-4.2.0: 20070514</p></li><li><p>gcc-4.2.1: 20070719</p></li><li><p>gcc-4.2.2: 20071007</p></li><li><p>gcc-4.2.3: 20080201</p></li><li><p>gcc-4.2.4: 20080519</p></li><li><p>gcc-4.3.0: 20080306</p></li><li><p>gcc-4.3.1: 20080606</p></li><li><p>gcc-4.3.2: 20080827</p></li></ul></div><p></p></li><li><p>
- Incremental bumping of a library pre-defined macro,
- _GLIBCPP_VERSION. This macro is defined as the released version of
- the library, as a string literal. This is only implemented in
- gcc-3.1.0 releases and higher, and is deprecated in 3.4 (where it
- is called _GLIBCXX_VERSION).
- </p><p>
- This macro is defined in the file "c++config" in the
- "libstdc++/include/bits" directory and is generated
- automatically by autoconf as part of the configure-time generation
- of config.h.
- </p><p>
- It is versioned as follows:
- </p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: "3.0.0"</p></li><li><p>gcc-3.0.1: "3.0.0" (Error, should be "3.0.1")</p></li><li><p>gcc-3.0.2: "3.0.0" (Error, should be "3.0.2")</p></li><li><p>gcc-3.0.3: "3.0.0" (Error, should be "3.0.3")</p></li><li><p>gcc-3.0.4: "3.0.0" (Error, should be "3.0.4")</p></li><li><p>gcc-3.1.0: "3.1.0"</p></li><li><p>gcc-3.1.1: "3.1.1"</p></li><li><p>gcc-3.2.0: "3.2"</p></li><li><p>gcc-3.2.1: "3.2.1"</p></li><li><p>gcc-3.2.2: "3.2.2"</p></li><li><p>gcc-3.2.3: "3.2.3"</p></li><li><p>gcc-3.3.0: "3.3"</p></li><li><p>gcc-3.3.1: "3.3.1"</p></li><li><p>gcc-3.3.2: "3.3.2"</p></li><li><p>gcc-3.3.3: "3.3.3"</p></li><li><p>gcc-3.4.x: "version-unused"</p></li><li><p>gcc-4.[0-3].x: "version-unused"</p></li></ul></div><p></p></li><li><p>
- Matching each specific C++ compiler release to a specific set of
- C++ include files. This is only implemented in gcc-3.1.1 releases
- and higher.
- </p><p>
- All C++ includes are installed in include/c++, then nest in a
- directory hierarchy corresponding to the C++ compiler's released
- version. This version corresponds to the variable "gcc_version" in
- "libstdc++/acinclude.m4," and more details can be found in that
- file's macro GLIBCXX_CONFIGURE (GLIBCPP_CONFIGURE before gcc-3.4.0).
- </p><p>
- C++ includes are versioned as follows:
- </p><div class="itemizedlist"><ul type="disc"><li><p>gcc-3.0.0: include/g++-v3</p></li><li><p>gcc-3.0.1: include/g++-v3</p></li><li><p>gcc-3.0.2: include/g++-v3</p></li><li><p>gcc-3.0.3: include/g++-v3</p></li><li><p>gcc-3.0.4: include/g++-v3</p></li><li><p>gcc-3.1.0: include/g++-v3</p></li><li><p>gcc-3.1.1: include/c++/3.1.1</p></li><li><p>gcc-3.2.0: include/c++/3.2</p></li><li><p>gcc-3.2.1: include/c++/3.2.1</p></li><li><p>gcc-3.2.2: include/c++/3.2.2</p></li><li><p>gcc-3.2.3: include/c++/3.2.3</p></li><li><p>gcc-3.3.0: include/c++/3.3</p></li><li><p>gcc-3.3.1: include/c++/3.3.1</p></li><li><p>gcc-3.3.2: include/c++/3.3.2</p></li><li><p>gcc-3.3.3: include/c++/3.3.3</p></li><li><p>gcc-3.4.0: include/c++/3.4.0</p></li><li><p>gcc-3.4.1: include/c++/3.4.1</p></li><li><p>gcc-3.4.2: include/c++/3.4.2</p></li><li><p>gcc-3.4.3: include/c++/3.4.3</p></li><li><p>gcc-3.4.4: include/c++/3.4.4</p></li><li><p>gcc-3.4.5: include/c++/3.4.5</p></li><li><p>gcc-3.4.6: include/c++/3.4.6</p></li><li><p>gcc-4.0.0: include/c++/4.0.0</p></li><li><p>gcc-4.0.1: include/c++/4.0.1</p></li><li><p>gcc-4.0.2: include/c++/4.0.2</p></li><li><p>gcc-4.0.3: include/c++/4.0.3</p></li><li><p>gcc-4.1.0: include/c++/4.1.0</p></li><li><p>gcc-4.1.1: include/c++/4.1.1</p></li><li><p>gcc-4.1.2: include/c++/4.1.2</p></li><li><p>gcc-4.2.0: include/c++/4.2.0</p></li><li><p>gcc-4.2.1: include/c++/4.2.1</p></li><li><p>gcc-4.2.2: include/c++/4.2.2</p></li><li><p>gcc-4.2.3: include/c++/4.2.3</p></li><li><p>gcc-4.2.4: include/c++/4.2.4</p></li><li><p>gcc-4.3.0: include/c++/4.3.0</p></li><li><p>gcc-4.3.1: include/c++/4.3.1</p></li><li><p>gcc-4.3.2: include/c++/4.3.2</p></li></ul></div><p></p></li></ol></div><p>
- Taken together, these techniques can accurately specify interface
- and implementation changes in the GNU C++ tools themselves. Used
- properly, they allow both the GNU C++ tools implementation, and
- programs using them, an evolving yet controlled development that
- maintains backward compatibility.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.prereq"></a>Prerequisites</h4></div></div></div><p>
- Minimum environment that supports a versioned ABI: A supported
- dynamic linker, a GNU linker of sufficient vintage to understand
- demangled C++ name globbing (ld), a shared executable compiled
- with g++, and shared libraries (libgcc_s, libstdc++) compiled by
- a compiler (g++) with a compatible ABI. Phew.
- </p><p>
- On top of all that, an additional constraint: libstdc++ did not
- attempt to version symbols (or age gracefully, really) until
- version 3.1.0.
- </p><p>
- Most modern Linux and BSD versions, particularly ones using
- gcc-3.1.x tools and more recent vintages, will meet the
- requirements above.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.config"></a>Configuring</h4></div></div></div><p>
- It turns out that most of the configure options that change
- default behavior will impact the mangled names of exported
- symbols, and thus impact versioning and compatibility.
- </p><p>
- For more information on configure options, including ABI
- impacts, see:
- http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html
- </p><p>
- There is one flag that explicitly deals with symbol versioning:
- --enable-symvers.
- </p><p>
- In particular, libstdc++/acinclude.m4 has a macro called
- GLIBCXX_ENABLE_SYMVERS that defaults to yes (or the argument
- passed in via --enable-symvers=foo). At that point, the macro
- attempts to make sure that all the requirement for symbol
- versioning are in place. For more information, please consult
- acinclude.m4.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.active"></a>Checking Active</h4></div></div></div><p>
- When the GNU C++ library is being built with symbol versioning
- on, you should see the following at configure time for
- libstdc++:
- </p><pre class="screen">
-<code class="computeroutput">
- checking versioning on shared library symbols... gnu
-</code>
-</pre><p>
- If you don't see this line in the configure output, or if this line
- appears but the last word is 'no', then you are out of luck.
-</p><p>
- If the compiler is pre-installed, a quick way to test is to compile
- the following (or any) simple C++ file and link it to the shared
- libstdc++ library:
-</p><pre class="programlisting">
-#include &lt;iostream&gt;
-
-int main()
-{ std::cout &lt;&lt; "hello" &lt;&lt; std::endl; return 0; }
-
-%g++ hello.cc -o hello.out
-
-%ldd hello.out
- libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x00764000)
- libm.so.6 =&gt; /lib/tls/libm.so.6 (0x004a8000)
- libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40016000)
- libc.so.6 =&gt; /lib/tls/libc.so.6 (0x0036d000)
- /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
-
-%nm hello.out
-</pre><p>
-If you see symbols in the resulting output with "GLIBCXX_3" as part
-of the name, then the executable is versioned. Here's an example:
-</p><p>
- <code class="code">U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4</code>
-</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.changes_allowed"></a>Allowed Changes</h3></div></div></div><p>
-The following will cause the library minor version number to
-increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.3.0.5".
-</p><div class="orderedlist"><ol type="1"><li><p>Adding an exported global or static data member</p></li><li><p>Adding an exported function, static or non-virtual member function</p></li><li><p>Adding an exported symbol or symbols by additional instantiations</p></li></ol></div><p>
-Other allowed changes are possible.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.changes_no"></a>Prohibited Changes</h3></div></div></div><p>
-The following non-exhaustive list will cause the library major version
-number to increase, say from "libstdc++.so.3.0.4" to
-"libstdc++.so.4.0.0".
-</p><div class="orderedlist"><ol type="1"><li><p>Changes in the gcc/g++ compiler ABI</p></li><li><p>Changing size of an exported symbol</p></li><li><p>Changing alignment of an exported symbol</p></li><li><p>Changing the layout of an exported symbol</p></li><li><p>Changing mangling on an exported symbol</p></li><li><p>Deleting an exported symbol</p></li><li><p>Changing the inheritance properties of a type by adding or removing
- base classes</p></li><li><p>
- Changing the size, alignment, or layout of types
- specified in the C++ standard. These may not necessarily be
- instantiated or otherwise exported in the library binary, and
- include all the required locale facets, as well as things like
- std::basic_streambuf, et al.
-</p></li><li><p> Adding an explicit copy constructor or destructor to a
-class that would otherwise have implicit versions. This will change
-the way the compiler deals with this class in by-value return
-statements or parameters: instead of being passing instances of this
-class in registers, the compiler will be forced to use memory. See <a class="ulink" href="http://www.codesourcery.com/cxx-abi/abi.html#calls" target="_top"> this part</a>
- of the C++ ABI documentation for further details.
- </p></li></ol></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.impl"></a>Implementation</h3></div></div></div><div class="orderedlist"><ol type="1"><li><p>
- Separation of interface and implementation
- </p><p>
- This is accomplished by two techniques that separate the API from
- the ABI: forcing undefined references to link against a library
- binary for definitions.
- </p><div class="variablelist"><dl><dt><span class="term">Include files have declarations, source files have defines</span></dt><dd><p>
- For non-templatized types, such as much of <code class="code">class
- locale</code>, the appropriate standard C++ include, say
- <code class="code">locale</code>, can contain full declarations, while
- various source files (say <code class="code"> locale.cc, locale_init.cc,
- localename.cc</code>) contain definitions.
- </p></dd><dt><span class="term">Extern template on required types</span></dt><dd><p>
- For parts of the standard that have an explicit list of
- required instantiations, the GNU extension syntax <code class="code"> extern
- template </code> can be used to control where template
- definitions reside. By marking required instantiations as
- <code class="code"> extern template </code> in include files, and providing
- explicit instantiations in the appropriate instantiation files,
- non-inlined template functions can be versioned. This technique
- is mostly used on parts of the standard that require <code class="code">
- char</code> and <code class="code"> wchar_t</code> instantiations, and
- includes <code class="code"> basic_string</code>, the locale facets, and the
- types in <code class="code"> iostreams</code>.
- </p></dd></dl></div><p>
- In addition, these techniques have the additional benefit that they
- reduce binary size, which can increase runtime performance.
- </p></li><li><p>
- Namespaces linking symbol definitions to export mapfiles
- </p><p>
- All symbols in the shared library binary are processed by a
- linker script at build time that either allows or disallows
- external linkage. Because of this, some symbols, regardless of
- normal C/C++ linkage, are not visible. Symbols that are internal
- have several appealing characteristics: by not exporting the
- symbols, there are no relocations when the shared library is
- started and thus this makes for faster runtime loading
- performance by the underlying dynamic loading mechanism. In
- addition, they have the possibility of changing without impacting
- ABI compatibility.
- </p><p>The following namespaces are transformed by the mapfile:</p><div class="variablelist"><dl><dt><span class="term"><code class="code">namespace std</code></span></dt><dd><p> Defaults to exporting all symbols in label
-<code class="code">GLIBCXX</code> that do not begin with an underscore, i.e.,
-<code class="code">__test_func</code> would not be exported by default. Select
-exceptional symbols are allowed to be visible.</p></dd><dt><span class="term"><code class="code">namespace __gnu_cxx</code></span></dt><dd><p> Defaults to not exporting any symbols in label
-<code class="code">GLIBCXX</code>, select items are allowed to be visible.</p></dd><dt><span class="term"><code class="code">namespace __gnu_internal</code></span></dt><dd><p> Defaults to not exported, no items are allowed to be visible.</p></dd><dt><span class="term"><code class="code">namespace __cxxabiv1</code>, aliased to <code class="code"> namespace abi</code></span></dt><dd><p> Defaults to not exporting any symbols in label
-<code class="code">CXXABI</code>, select items are allowed to be visible.</p></dd></dl></div><p>
-</p></li><li><p>Freezing the API</p><p>Disallowed changes, as above, are not made on a stable release
-branch. Enforcement tends to be less strict with GNU extensions that
-standard includes.</p></li></ol></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.testing"></a>Testing</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.testing.single"></a>Single ABI Testing</h4></div></div></div><p>
- Testing for GNU C++ ABI changes is composed of two distinct
- areas: testing the C++ compiler (g++) for compiler changes, and
- testing the C++ library (libstdc++) for library changes.
- </p><p>
- Testing the C++ compiler ABI can be done various ways.
- </p><p>
- One. Intel ABI checker. More information can be obtained <a class="ulink" href="http://developer.intel.com/software/products/opensource/" target="_top">here.</a>
- </p><p>
-Two.
-The second is yet unreleased, but has been announced on the gcc
-mailing list. It is yet unspecified if these tools will be freely
-available, and able to be included in a GNU project. Please contact
-Mark Mitchell (mark@codesourcery.com) for more details, and current
-status.
-</p><p>
-Three.
-Involves using the vlad.consistency test framework. This has also been
-discussed on the gcc mailing lists.
-</p><p>
-Testing the C++ library ABI can also be done various ways.
-</p><p>
-One.
-(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways,
-one with a new compiler and an old library, and the other with an old
-compiler and a new library, and look for testsuite regressions)
-</p><p>
-Details on how to set this kind of test up can be found here:
-http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html
-</p><p>
-Two.
-Use the 'make check-abi' rule in the libstdc++ Makefile.
-</p><p>
-This is a proactive check the library ABI. Currently, exported symbol
-names that are either weak or defined are checked against a last known
-good baseline. Currently, this baseline is keyed off of 3.4.0
-binaries, as this was the last time the .so number was incremented. In
-addition, all exported names are demangled, and the exported objects
-are checked to make sure they are the same size as the same object in
-the baseline.
-
-Notice that each baseline is relative to a <span class="emphasis"><em>default</em></span>
-configured library and compiler: in particular, if options such as
---enable-clocale, or --with-cpu, in case of multilibs, are used at
-configure time, the check may fail, either because of substantive
-differences or because of limitations of the current checking
-machinery.
-</p><p>
-This dataset is insufficient, yet a start. Also needed is a
-comprehensive check for all user-visible types part of the standard
-library for sizeof() and alignof() changes.
-</p><p>
-Verifying compatible layouts of objects is not even attempted. It
-should be possible to use sizeof, alignof, and offsetof to compute
-offsets for each structure and type in the standard library, saving to
-another datafile. Then, compute this in a similar way for new
-binaries, and look for differences.
-</p><p>
-Another approach might be to use the -fdump-class-hierarchy flag to
-get information. However, currently this approach gives insufficient
-data for use in library testing, as class data members, their offsets,
-and other detailed data is not displayed with this flag.
-(See g++/7470 on how this was used to find bugs.)
-</p><p>
-Perhaps there are other C++ ABI checkers. If so, please notify
-us. We'd like to know about them!
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="abi.testing.multi"></a>Multiple ABI Testing</h4></div></div></div><p>
-A "C" application, dynamically linked to two shared libraries, liba,
-libb. The dependent library liba is C++ shared library compiled with
-gcc-3.3.x, and uses io, exceptions, locale, etc. The dependent library
-libb is a C++ shared library compiled with gcc-3.4.x, and also uses io,
-exceptions, locale, etc.
-</p><p> As above, libone is constructed as follows: </p><pre class="programlisting">
-%$bld/H-x86-gcc-3.4.0/bin/g++ -fPIC -DPIC -c a.cc
-
-%$bld/H-x86-gcc-3.4.0/bin/g++ -shared -Wl,-soname -Wl,libone.so.1 -Wl,-O1 -Wl,-z,defs a.o -o libone.so.1.0.0
-
-%ln -s libone.so.1.0.0 libone.so
-
-%$bld/H-x86-gcc-3.4.0/bin/g++ -c a.cc
-
-%ar cru libone.a a.o
-</pre><p> And, libtwo is constructed as follows: </p><pre class="programlisting">
-%$bld/H-x86-gcc-3.3.3/bin/g++ -fPIC -DPIC -c b.cc
-
-%$bld/H-x86-gcc-3.3.3/bin/g++ -shared -Wl,-soname -Wl,libtwo.so.1 -Wl,-O1 -Wl,-z,defs b.o -o libtwo.so.1.0.0
-
-%ln -s libtwo.so.1.0.0 libtwo.so
-
-%$bld/H-x86-gcc-3.3.3/bin/g++ -c b.cc
-
-%ar cru libtwo.a b.o
-</pre><p> ...with the resulting libraries looking like </p><pre class="screen">
-<code class="computeroutput">
-%ldd libone.so.1.0.0
- libstdc++.so.6 =&gt; /usr/lib/libstdc++.so.6 (0x40016000)
- libm.so.6 =&gt; /lib/tls/libm.so.6 (0x400fa000)
- libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x4011c000)
- libc.so.6 =&gt; /lib/tls/libc.so.6 (0x40125000)
- /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
-
-%ldd libtwo.so.1.0.0
- libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x40027000)
- libm.so.6 =&gt; /lib/tls/libm.so.6 (0x400e1000)
- libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40103000)
- libc.so.6 =&gt; /lib/tls/libc.so.6 (0x4010c000)
- /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
-</code>
-</pre><p>
- Then, the "C" compiler is used to compile a source file that uses
- functions from each library.
-</p><pre class="programlisting">
-gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.6
-</pre><p>
- Which gives the expected:
-</p><pre class="screen">
-<code class="computeroutput">
-%ldd a.out
- libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x00764000)
- libstdc++.so.6 =&gt; /usr/lib/libstdc++.so.6 (0x40015000)
- libc.so.6 =&gt; /lib/tls/libc.so.6 (0x0036d000)
- libm.so.6 =&gt; /lib/tls/libm.so.6 (0x004a8000)
- libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x400e5000)
- /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
-</code>
-</pre><p>
- This resulting binary, when executed, will be able to safely use
- code from both liba, and the dependent libstdc++.so.6, and libb,
- with the dependent libstdc++.so.5.
-</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="abi.issues"></a>Outstanding Issues</h3></div></div></div><p>
- Some features in the C++ language make versioning especially
- difficult. In particular, compiler generated constructs such as
- implicit instantiations for templates, typeinfo information, and
- virtual tables all may cause ABI leakage across shared library
- boundaries. Because of this, mixing C++ ABIs is not recommended at
- this time.
-</p><p>
- For more background on this issue, see these bugzilla entries:
-</p><p>
-<a class="ulink" href="http://gcc.gnu.org/PR24660" target="_top">24660: versioning weak symbols in libstdc++</a>
-</p><p>
-<a class="ulink" href="http://gcc.gnu.org/PR19664" target="_top">19664: libstdc++ headers should have pop/push of the visibility around the declarations</a>
-</p></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="abi.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id430252"></a><p><span class="title"><i>
- ABIcheck, a vague idea of checking ABI compatibility
- </i>. </span><span class="biblioid">
- <a class="ulink" href="http://abicheck.sourceforge.net/" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id430269"></a><p><span class="title"><i>
- C++ ABI Reference
- </i>. </span><span class="biblioid">
- <a class="ulink" href="http://www.codesourcery.com/cxx-abi" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id430287"></a><p><span class="title"><i>
- Intel® Compilers for Linux* -Compatibility with the GNU Compilers
- </i>. </span><span class="biblioid">
- <a class="ulink" href="http://developer.intel.com/software/products/compilers/techtopics/LinuxCompilersCompatibility.htm" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id430304"></a><p><span class="title"><i>
- Intel® Compilers for Linux* -Compatibility with the GNU Compilers
- </i>. </span><span class="biblioid">
- <a class="ulink" href="http://developer.intel.com/software/products/compilers/techtopics/LinuxCompilersCompatibility.htm" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id430322"></a><p><span class="title"><i>
- Sun Solaris 2.9 : Linker and Libraries Guide (document 816-1386)
- </i>. </span><span class="biblioid">
- <a class="ulink" href="http://docs.sun.com/?p=/doc/816-1386&amp;a=load" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id430339"></a><p><span class="title"><i>
- Sun Solaris 2.9 : C++ Migration Guide (document 816-2459)
- </i>. </span><span class="biblioid">
- <a class="ulink" href="http://docs.sun.com/db/prod/solaris.9" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id430356"></a><p><span class="title"><i>
- ELF Symbol Versioning
- </i>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="biblioid">
- <a class="ulink" href="http://people.redhat.com/drepper/symbol-versioning" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id430385"></a><p><span class="title"><i>
- C++ ABI for the ARM Architecture
- </i>. </span><span class="biblioid">
- <a class="ulink" href="http://www.arm.com/miscPDFs/8033.pdf" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id430402"></a><p><span class="title"><i>
- Dynamic Shared Objects: Survey and Issues
- </i>. </span><span class="subtitle">
- ISO C++ J16/06-0046
- . </span><span class="author"><span class="firstname">Benjamin</span> <span class="surname">Kosnik</span>. </span><span class="biblioid">
- <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1976.html" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id430434"></a><p><span class="title"><i>
- Versioning With Namespaces
- </i>. </span><span class="subtitle">
- ISO C++ J16/06-0083
- . </span><span class="author"><span class="firstname">Benjamin</span> <span class="surname">Kosnik</span>. </span><span class="biblioid">
- <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2013.html" target="_top">
- </a>
- . </span></p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="internals.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_porting.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Porting to New Hardware or Operating Systems </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> API Evolution and Deprecation History</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/algorithms.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/algorithms.html
deleted file mode 100644
index 3ee170afd..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/algorithms.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part IX.  Algorithms</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; , &#10; algorithm&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="bk01pt08ch19s02.html" title="One Past the End" /><link rel="next" href="bk01pt09pr02.html" title="" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part IX. 
- Algorithms
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt08ch19s02.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt09pr02.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.algorithms"></a>Part IX. 
- Algorithms
- <a id="id426726" class="indexterm"></a>
-</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="bk01pt09pr02.html"></a></span></dt><dt><span class="chapter"><a href="bk01pt09ch20.html">20. Mutating</a></span></dt><dd><dl><dt><span class="sect1"><a href="bk01pt09ch20.html#algorithms.mutating.swap">swap</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt09ch20.html#algorithms.swap.specializations">Specializations</a></span></dt></dl></dd></dl></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt08ch19s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt09pr02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">One Past the End </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/api.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/api.html
deleted file mode 100644
index de0ec11d8..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/api.html
+++ /dev/null
@@ -1,154 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>API Evolution and Deprecation History</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="ISO C++, api, evolution, deprecation, history" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_porting.html" title="Appendix B.  Porting and Maintenance" /><link rel="prev" href="abi.html" title="ABI Policy and Guidelines" /><link rel="next" href="backwards.html" title="Backwards Compatibility" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">API Evolution and Deprecation History</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="abi.html">Prev</a> </td><th width="60%" align="center">Appendix B. 
- Porting and Maintenance
-
-</th><td width="20%" align="right"> <a accesskey="n" href="backwards.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="appendix.porting.api"></a>API Evolution and Deprecation History</h2></div></div></div><p>
-A list of user-visible changes, in chronological order
-</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_300"></a><code class="constant">3.0</code></h3></div></div></div><p>
-Extensions moved to <code class="filename">include/ext</code>.
- </p><p>
-Include files from the SGI/HP sources that pre-date the ISO standard
-are added. These files are placed into
-the <code class="filename">include/backward</code> directory and a deprecated warning
-is added that notifies on inclusion (<code class="literal">-Wno-deprecated</code>
-deactivates the warning.)
-</p><p>Deprecated include <code class="filename">backward/strstream</code> added.</p><p>Removal of include <code class="filename">builtinbuf.h</code>, <code class="filename">indstream.h</code>, <code class="filename">parsestream.h</code>, <code class="filename">PlotFile.h</code>, <code class="filename">SFile.h</code>, <code class="filename">stdiostream.h</code>, and <code class="filename">stream.h</code>.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_310"></a><code class="constant">3.1</code></h3></div></div></div><p>
- </p><p>
-Extensions from SGI/HP moved from <code class="code">namespace std</code>
-to <code class="code">namespace __gnu_cxx</code>. As part of this, the following
-new includes are
-added: <code class="filename">ext/algorithm</code>, <code class="filename">ext/functional</code>, <code class="filename">ext/iterator</code>, <code class="filename">ext/memory</code>, and <code class="filename">ext/numeric</code>.
-</p><p>
-Extensions to <code class="code">basic_filebuf</code> introduced: <code class="code">__gnu_cxx::enc_filebuf</code>, and <code class="code">__gnu_cxx::stdio_filebuf</code>.
-</p><p>
-Extensions to tree data structures added in <code class="filename">ext/rb_tree</code>.
-</p><p>
-Removal of <code class="filename">ext/tree</code>, moved to <code class="filename">backward/tree.h</code>.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_320"></a><code class="constant">3.2</code></h3></div></div></div><p>
- </p><p>Symbol versioning introduced for shared library.</p><p>Removal of include <code class="filename">backward/strstream.h</code>.</p><p>Allocator changes. Change <code class="code">__malloc_alloc</code> to <code class="code">malloc_allocator</code> and <code class="code">__new_alloc</code> to <code class="code">new_allocator</code>. </p><p> For GCC releases from 2.95 through the 3.1 series, defining
- <code class="literal">__USE_MALLOC</code> on the gcc command line would change the
- default allocation strategy to instead use <code class="code"> malloc</code> and
- <code class="function">free</code>. See
- <a class="ulink" href="../23_containers/howto.html#3" target="_top">this note</a>
- for details as to why this was something needing improvement.
- </p><p>Error handling in iostreams cleaned up, made consistent. </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_330"></a><code class="constant">3.3</code></h3></div></div></div><p>
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_340"></a><code class="constant">3.4</code></h3></div></div></div><p>
- </p><p>
-Large file support.
-</p><p> Extensions for generic characters and <code class="code">char_traits</code> added in <code class="filename">ext/pod_char_traits.h</code>.
-</p><p>
-Support for <code class="code">wchar_t</code> specializations of <code class="code">basic_filebuf</code> enhanced to support <code class="code">UTF-8</code> and <code class="code">Unicode</code>, depending on host. More hosts support basic <code class="code">wchar_t</code> functionality.
-</p><p>
-Support for <code class="code">char_traits</code> beyond builtin types.
-</p><p>
-Conformant <code class="code">allocator</code> class and usage in containers. As
-part of this, the following extensions are
-added: <code class="filename">ext/bitmap_allocator.h</code>, <code class="filename">ext/debug_allocator.h</code>, <code class="filename">ext/mt_allocator.h</code>, <code class="filename">ext/malloc_allocator.h</code>,<code class="filename">ext/new_allocator.h</code>, <code class="filename">ext/pool_allocator.h</code>.
-</p><p>
-This is a change from all previous versions, and may require
-source-level changes due to allocator-related changes to structures
-names and template parameters, filenames, and file locations. Some,
-like <code class="code">__simple_alloc, __allocator, __alloc, </code> and <code class="code">
-_Alloc_traits</code> have been removed.
-</p><p>Default behavior of <code class="code">std::allocator</code> has changed.</p><p>
- Previous versions prior to 3.4 cache allocations in a memory
- pool, instead of passing through to call the global allocation
- operators (i.e., <code class="classname">__gnu_cxx::pool_allocator</code>). More
- recent versions default to the
- simpler <code class="classname">__gnu_cxx::new_allocator</code>.
-</p><p> Previously, all allocators were written to the SGI
- style, and all STL containers expected this interface. This
- interface had a traits class called <code class="code">_Alloc_traits</code> that
- attempted to provide more information for compile-time allocation
- selection and optimization. This traits class had another allocator
- wrapper, <code class="code">__simple_alloc&lt;T,A&gt;</code>, which was a
- wrapper around another allocator, A, which itself is an allocator
- for instances of T. But wait, there's more:
- <code class="code">__allocator&lt;T,A&gt;</code> is another adapter. Many of
- the provided allocator classes were SGI style: such classes can be
- changed to a conforming interface with this wrapper:
- <code class="code">__allocator&lt;T, __alloc&gt;</code> is thus the same as
- <code class="code">allocator&lt;T&gt;</code>.
- </p><p> The class <code class="classname">allocator</code> used the typedef
- <span class="type">__alloc</span> to select an underlying allocator that
- satisfied memory allocation requests. The selection of this
- underlying allocator was not user-configurable.
- </p><div class="table"><a id="id433248"></a><p class="title"><b>Table B.1. Extension Allocators</b></p><div class="table-contents"><table summary="Extension Allocators" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><thead><tr><th align="left">Allocator (3.4)</th><th align="left">Header (3.4)</th><th align="left">Allocator (3.[0-3])</th><th align="left">Header (3.[0-3])</th></tr></thead><tbody><tr><td align="left"><code class="classname">__gnu_cxx::new_allocator&lt;T&gt;</code></td><td align="left"><code class="filename">ext/new_allocator.h</code></td><td align="left"><code class="classname">std::__new_alloc</code></td><td align="left"><code class="filename">memory</code></td></tr><tr><td align="left"><code class="classname">__gnu_cxx::malloc_allocator&lt;T&gt;</code></td><td align="left"><code class="filename">ext/malloc_allocator.h</code></td><td align="left"><code class="classname">std::__malloc_alloc_template&lt;int&gt;</code></td><td align="left"><code class="filename">memory</code></td></tr><tr><td align="left"><code class="classname">__gnu_cxx::debug_allocator&lt;T&gt;</code></td><td align="left"><code class="filename">ext/debug_allocator.h</code></td><td align="left"><code class="classname">std::debug_alloc&lt;T&gt;</code></td><td align="left"><code class="filename">memory</code></td></tr><tr><td align="left"><code class="classname">__gnu_cxx::__pool_alloc&lt;T&gt;</code></td><td align="left"><code class="filename">ext/pool_allocator.h</code></td><td align="left"><code class="classname">std::__default_alloc_template&lt;bool,int&gt;</code></td><td align="left"><code class="filename">memory</code></td></tr><tr><td align="left"><code class="classname">__gnu_cxx::__mt_alloc&lt;T&gt;</code></td><td align="left"><code class="filename">ext/mt_allocator.h</code></td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left"><code class="classname">__gnu_cxx::bitmap_allocator&lt;T&gt;</code></td><td align="left"><code class="filename">ext/bitmap_allocator.h</code></td><td align="left"> </td><td align="left"> </td></tr></tbody></table></div></div><br class="table-break" /><p> Releases after gcc-3.4 have continued to add to the collection
- of available allocators. All of these new allocators are
- standard-style. The following table includes details, along with
- the first released version of GCC that included the extension allocator.
- </p><div class="table"><a id="id433479"></a><p class="title"><b>Table B.2. Extension Allocators Continued</b></p><div class="table-contents"><table summary="Extension Allocators Continued" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /></colgroup><thead><tr><th align="left">Allocator</th><th align="left">Include</th><th align="left">Version</th></tr></thead><tbody><tr><td align="left"><code class="classname">__gnu_cxx::array_allocator&lt;T&gt;</code></td><td align="left"><code class="filename">ext/array_allocator.h</code></td><td align="left">4.0.0</td></tr><tr><td align="left"><code class="classname">__gnu_cxx::throw_allocator&lt;T&gt;</code></td><td align="left"><code class="filename">ext/throw_allocator.h</code></td><td align="left">4.2.0</td></tr></tbody></table></div></div><br class="table-break" /><p>
-Debug mode first appears.
-</p><p>
-Precompiled header support <acronym class="acronym">PCH</acronym> support.
-</p><p>
-Macro guard for changed, from <code class="literal">_GLIBCPP_</code> to <code class="literal">_GLIBCXX_</code>.
-</p><p>
-Extension <code class="filename">ext/stdio_sync_filebuf.h</code> added.
-</p><p>
-Extension <code class="filename">ext/demangle.h</code> added.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_400"></a><code class="constant">4.0</code></h3></div></div></div><p>
- </p><p>
-TR1 features first appear.
-</p><p>
-Extension allocator <code class="filename">ext/array_allocator.h</code> added.
-</p><p>
-Extension <code class="code">codecvt</code> specializations moved to <code class="filename">ext/codecvt_specializations.h</code>.
-</p><p>
-Removal of <code class="filename">ext/demangle.h</code>.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_410"></a><code class="constant">4.1</code></h3></div></div></div><p>
- </p><p>
-Removal of <code class="filename">cassert</code> from all standard headers: now has to be explicitly included for <code class="code">std::assert</code> calls.
-</p><p> Extensions for policy-based data structures first added. New includes,
-types, namespace <code class="code">pb_assoc</code>.
-</p><p> Extensions for typelists added in <code class="filename">ext/typelist.h</code>.
-</p><p> Extension for policy-based <code class="code">basic_string</code> first added: <code class="code">__gnu_cxx::__versa_string</code> in <code class="filename">ext/vstring.h</code>.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_420"></a><code class="constant">4.2</code></h3></div></div></div><p>
- </p><p> Default visibility attributes applied to <code class="code">namespace std</code>. Support for <code class="code">-fvisibility</code>.
-</p><p>TR1 <code class="filename">random</code>, <code class="filename">complex</code>, and C compatibility headers added.</p><p> Extensions for concurrent programming consolidated
-into <code class="filename">ext/concurrence.h</code> and <code class="filename">ext/atomicity.h</code>,
-including change of namespace to <code class="code">__gnu_cxx</code> in some
-cases. Added types
-include <code class="code">_Lock_policy</code>, <code class="code">__concurrence_lock_error</code>, <code class="code">__concurrence_unlock_error</code>, <code class="code">__mutex</code>, <code class="code">__scoped_lock</code>.</p><p> Extensions for type traits consolidated
-into <code class="filename">ext/type_traits.h</code>. Additional traits are added
-(<code class="code">__conditional_type</code>, <code class="code">__enable_if</code>, others.)
-</p><p> Extensions for policy-based data structures revised. New includes,
-types, namespace moved to <code class="code">__pb_ds</code>.
-</p><p> Extensions for debug mode modified: now nested in <code class="code">namespace
-std::__debug</code> and extensions in <code class="code">namespace
-__gnu_cxx::__debug</code>.</p><p> Extensions added: <code class="filename">ext/typelist.h</code>
-and <code class="filename">ext/throw_allocator.h</code>.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_430"></a><code class="constant">4.3</code></h3></div></div></div><p>
- </p><p>
-C++0X features first appear.
-</p><p>TR1 <code class="filename">regex</code> and <code class="filename">cmath</code>'s mathematical special function added.</p><p>
-Backward include edit.
-</p><div class="itemizedlist"><ul type="disc"><li><p>Removed</p><p>
-<code class="filename">algobase.h</code> <code class="filename">algo.h</code> <code class="filename">alloc.h</code> <code class="filename">bvector.h</code> <code class="filename">complex.h</code>
-<code class="filename">defalloc.h</code> <code class="filename">deque.h</code> <code class="filename">fstream.h</code> <code class="filename">function.h</code> <code class="filename">hash_map.h</code> <code class="filename">hash_set.h</code>
-<code class="filename">hashtable.h</code> <code class="filename">heap.h</code> <code class="filename">iomanip.h</code> <code class="filename">iostream.h</code> <code class="filename">istream.h</code> <code class="filename">iterator.h</code>
-<code class="filename">list.h</code> <code class="filename">map.h</code> <code class="filename">multimap.h</code> <code class="filename">multiset.h</code> <code class="filename">new.h</code> <code class="filename">ostream.h</code> <code class="filename">pair.h</code> <code class="filename">queue.h</code> <code class="filename">rope.h</code> <code class="filename">set.h</code> <code class="filename">slist.h</code> <code class="filename">stack.h</code> <code class="filename">streambuf.h</code> <code class="filename">stream.h</code> <code class="filename">tempbuf.h</code>
-<code class="filename">tree.h</code> <code class="filename">vector.h</code>
- </p></li><li><p>Added</p><p>
- <code class="filename">hash_map</code> and <code class="filename">hash_set</code>
- </p></li><li><p>Added in C++0x</p><p>
- <code class="filename">auto_ptr.h</code> and <code class="filename">binders.h</code>
- </p></li></ul></div><p>
-Header dependency streamlining.
-</p><div class="itemizedlist"><ul type="disc"><li><p><code class="filename">algorithm</code> no longer includes <code class="filename">climits</code>, <code class="filename">cstring</code>, or <code class="filename">iosfwd</code> </p></li><li><p><code class="filename">bitset</code> no longer includes <code class="filename">istream</code> or <code class="filename">ostream</code>, adds <code class="filename">iosfwd</code> </p></li><li><p><code class="filename">functional</code> no longer includes <code class="filename">cstddef</code></p></li><li><p><code class="filename">iomanip</code> no longer includes <code class="filename">istream</code>, <code class="filename">istream</code>, or <code class="filename">functional</code>, adds <code class="filename">ioswd</code> </p></li><li><p><code class="filename">numeric</code> no longer includes <code class="filename">iterator</code></p></li><li><p><code class="filename">string</code> no longer includes <code class="filename">algorithm</code> or <code class="filename">memory</code></p></li><li><p><code class="filename">valarray</code> no longer includes <code class="filename">numeric</code> or <code class="filename">cstdlib</code></p></li><li><p><code class="filename">tr1/hashtable</code> no longer includes <code class="filename">memory</code> or <code class="filename">functional</code></p></li><li><p><code class="filename">tr1/memory</code> no longer includes <code class="filename">algorithm</code></p></li><li><p><code class="filename">tr1/random</code> no longer includes <code class="filename">algorithm</code> or <code class="filename">fstream</code></p></li></ul></div><p>
-Debug mode for <code class="filename">unordered_map</code> and <code class="filename">unordered_set</code>.
-</p><p>
-Parallel mode first appears.
-</p><p>Variadic template implementations of items in <code class="filename">tuple</code> and
- <code class="filename">functional</code>.
-</p><p>Default <code class="code">what</code> implementations give more elaborate
- exception strings for <code class="code">bad_cast</code>,
- <code class="code">bad_typeid</code>, <code class="code">bad_exception</code>, and
- <code class="code">bad_alloc</code>.
-</p><p>
-PCH binary files no longer installed. Instead, the source files are installed.
-</p><p>
-Namespace pb_ds moved to __gnu_pb_ds.
-</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="abi.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_porting.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="backwards.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">ABI Policy and Guidelines </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Backwards Compatibility</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_contributing.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_contributing.html
deleted file mode 100644
index 9b030036b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_contributing.html
+++ /dev/null
@@ -1,113 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Appendix A.  Contributing</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="bk01pt12ch40s03.html" title="Use" /><link rel="next" href="source_organization.html" title="Directory Layout and Source Conventions" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix A. 
- Contributing
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch40s03.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="source_organization.html">Next</a></td></tr></table><hr /></div><div class="appendix" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="appendix.contrib"></a>Appendix A. 
- Contributing
- <a id="id495630" class="indexterm"></a>
-</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="appendix_contributing.html#contrib.list">Contributor Checklist</a></span></dt><dd><dl><dt><span class="sect2"><a href="appendix_contributing.html#list.reading">Reading</a></span></dt><dt><span class="sect2"><a href="appendix_contributing.html#list.copyright">Assignment</a></span></dt><dt><span class="sect2"><a href="appendix_contributing.html#list.getting">Getting Sources</a></span></dt><dt><span class="sect2"><a href="appendix_contributing.html#list.patches">Submitting Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="source_organization.html">Directory Layout and Source Conventions</a></span></dt><dt><span class="sect1"><a href="source_code_style.html">Coding Style</a></span></dt><dd><dl><dt><span class="sect2"><a href="source_code_style.html#coding_style.bad_identifiers">Bad Identifiers</a></span></dt><dt><span class="sect2"><a href="source_code_style.html#coding_style.example">By Example</a></span></dt></dl></dd><dt><span class="sect1"><a href="documentation_style.html">Documentation Style</a></span></dt><dd><dl><dt><span class="sect2"><a href="documentation_style.html#doc_style.doxygen">Doxygen</a></span></dt><dt><span class="sect2"><a href="documentation_style.html#doc_style.docbook">Docbook</a></span></dt></dl></dd><dt><span class="sect1"><a href="source_design_notes.html">Design Notes</a></span></dt></dl></div><p>
- The GNU C++ Library follows an open development model. Active
- contributors are assigned maintainer-ship responsibility, and given
- write access to the source repository. First time contributors
- should follow this procedure:
-</p><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contrib.list"></a>Contributor Checklist</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="list.reading"></a>Reading</h3></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
- Get and read the relevant sections of the C++ language
- specification. Copies of the full ISO 14882 standard are
- available on line via the ISO mirror site for committee
- members. Non-members, or those who have not paid for the
- privilege of sitting on the committee and sustained their
- two meeting commitment for voting rights, may get a copy of
- the standard from their respective national standards
- organization. In the USA, this national standards
- organization is ANSI and their web-site is right
- <a class="ulink" href="http://www.ansi.org" target="_top">here.</a>
- (And if you've already registered with them, clicking this link will take you to directly to the place where you can
- <a class="ulink" href="http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%3A2003" target="_top">buy the standard on-line.)</a>
- </p></li><li><p>
- The library working group bugs, and known defects, can
- be obtained here:
- <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/" target="_top">http://www.open-std.org/jtc1/sc22/wg21 </a>
- </p></li><li><p>
- The newsgroup dedicated to standardization issues is
- comp.std.c++: this FAQ for this group is quite useful and
- can be
- found <a class="ulink" href="http://www.jamesd.demon.co.uk/csc/faq.html" target="_top">
- here </a>.
- </p></li><li><p>
- Peruse
- the <a class="ulink" href="http://www.gnu.org/prep/standards_toc.html" target="_top">GNU
- Coding Standards</a>, and chuckle when you hit the part
- about “<span class="quote">Using Languages Other Than C</span>”.
- </p></li><li><p>
- Be familiar with the extensions that preceded these
- general GNU rules. These style issues for libstdc++ can be
- found <a class="link" href="source_code_style.html" title="Coding Style">here</a>.
- </p></li><li><p>
- And last but certainly not least, read the
- library-specific information
- found <a class="link" href="appendix_porting.html" title="Appendix B.  Porting and Maintenance"> here</a>.
- </p></li></ul></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="list.copyright"></a>Assignment</h3></div></div></div><p>
- Small changes can be accepted without a copyright assignment form on
- file. New code and additions to the library need completed copyright
- assignment form on file at the FSF. Note: your employer may be required
- to fill out appropriate disclaimer forms as well.
- </p><p>
- Historically, the libstdc++ assignment form added the following
- question:
- </p><p>
- “<span class="quote">
- Which Belgian comic book character is better, Tintin or Asterix, and
- why?
- </span>”
- </p><p>
- While not strictly necessary, humoring the maintainers and answering
- this question would be appreciated.
- </p><p>
- For more information about getting a copyright assignment, please see
- <a class="ulink" href="http://www.gnu.org/prep/maintain/html_node/Legal-Matters.html" target="_top">Legal
- Matters</a>.
- </p><p>
- Please contact Benjamin Kosnik at
- <code class="email">&lt;<a class="email" href="mailto:bkoz+assign@redhat.com">bkoz+assign@redhat.com</a>&gt;</code> if you are confused
- about the assignment or have general licensing questions. When
- requesting an assignment form from
- <code class="email">&lt;<a class="email" href="mailto:mailto:assign@gnu.org">mailto:assign@gnu.org</a>&gt;</code>, please cc the libstdc++
- maintainer above so that progress can be monitored.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="list.getting"></a>Getting Sources</h3></div></div></div><p>
- <a class="ulink" href="http://gcc.gnu.org/svnwrite.html" target="_top">Getting write access
- (look for "Write after approval")</a>
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="list.patches"></a>Submitting Patches</h3></div></div></div><p>
- Every patch must have several pieces of information before it can be
- properly evaluated. Ideally (and to ensure the fastest possible
- response from the maintainers) it would have all of these pieces:
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- A description of the bug and how your patch fixes this
- bug. For new features a description of the feature and your
- implementation.
- </p></li><li><p>
- A ChangeLog entry as plain text; see the various
- ChangeLog files for format and content. If using you are
- using emacs as your editor, simply position the insertion
- point at the beginning of your change and hit CX-4a to bring
- up the appropriate ChangeLog entry. See--magic! Similar
- functionality also exists for vi.
- </p></li><li><p>
- A testsuite submission or sample program that will
- easily and simply show the existing error or test new
- functionality.
- </p></li><li><p>
- The patch itself. If you are accessing the SVN
- repository use <span class="command"><strong>svn update; svn diff NEW</strong></span>;
- else, use <span class="command"><strong>diff -cp OLD NEW</strong></span> ... If your
- version of diff does not support these options, then get the
- latest version of GNU
- diff. The <a class="ulink" href="http://gcc.gnu.org/wiki/SvnTricks" target="_top">SVN
- Tricks</a> wiki page has information on customising the
- output of <code class="code">svn diff</code>.
- </p></li><li><p>
- When you have all these pieces, bundle them up in a
- mail message and send it to libstdc++@gcc.gnu.org. All
- patches and related discussion should be sent to the
- libstdc++ mailing list.
- </p></li></ul></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch40s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="source_organization.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Use </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Directory Layout and Source Conventions</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_free.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_free.html
deleted file mode 100644
index 6ec51fc2c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_free.html
+++ /dev/null
@@ -1,124 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Appendix C.  Free Software Needs Free Documentation</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="backwards.html" title="Backwards Compatibility" /><link rel="next" href="appendix_gpl.html" title="Appendix D.  GNU General Public License version 3" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix C. 
- Free Software Needs Free Documentation
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="backwards.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="appendix_gpl.html">Next</a></td></tr></table><hr /></div><div class="appendix" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="appendix.free"></a>Appendix C. 
- Free Software Needs Free Documentation
- <a id="id511835" class="indexterm"></a>
-</h2></div></div></div><p>
-The biggest deficiency in free operating systems is not in the
-software--it is the lack of good free manuals that we can include in
-these systems. Many of our most important programs do not come with
-full manuals. Documentation is an essential part of any software
-package; when an important free software package does not come with a
-free manual, that is a major gap. We have many such gaps today.
-</p><p>
-Once upon a time, many years ago, I thought I would learn Perl. I got
-a copy of a free manual, but I found it hard to read. When I asked
-Perl users about alternatives, they told me that there were better
-introductory manuals--but those were not free.
-</p><p>
-Why was this? The authors of the good manuals had written them for
-O'Reilly Associates, which published them with restrictive terms--no
-copying, no modification, source files not available--which exclude
-them from the free software community.
-</p><p>
-That wasn't the first time this sort of thing has happened, and (to
-our community's great loss) it was far from the last. Proprietary
-manual publishers have enticed a great many authors to restrict their
-manuals since then. Many times I have heard a GNU user eagerly tell
-me about a manual that he is writing, with which he expects to help
-the GNU project--and then had my hopes dashed, as he proceeded to
-explain that he had signed a contract with a publisher that would
-restrict it so that we cannot use it.
-</p><p>
-Given that writing good English is a rare skill among programmers, we
-can ill afford to lose manuals this way.
-</p><p>
- Free documentation, like free software, is a matter of freedom,
-not price. The problem with these manuals was not that O'Reilly
-Associates charged a price for printed copies--that in itself is fine.
-(The Free Software Foundation <a class="ulink" href="http://www.gnu.org/doc/doc.html" target="_top">sells printed copies</a> of
-free GNU manuals, too.) But GNU manuals are available in source code
-form, while these manuals are available only on paper. GNU manuals
-come with permission to copy and modify; the Perl manuals do not.
-These restrictions are the problems.
-</p><p>
-The criterion for a free manual is pretty much the same as for free
-software: it is a matter of giving all users certain freedoms.
-Redistribution (including commercial redistribution) must be
-permitted, so that the manual can accompany every copy of the program,
-on-line or on paper. Permission for modification is crucial too.
-</p><p>
-As a general rule, I don't believe that it is essential for people to
-have permission to modify all sorts of articles and books. The issues
-for writings are not necessarily the same as those for software. For
-example, I don't think you or I are obliged to give permission to
-modify articles like this one, which describe our actions and our
-views.
-</p><p>
-But there is a particular reason why the freedom to modify is crucial
-for documentation for free software. When people exercise their right
-to modify the software, and add or change its features, if they are
-conscientious they will change the manual too--so they can provide
-accurate and usable documentation with the modified program. A manual
-which forbids programmers to be conscientious and finish the job, or
-more precisely requires them to write a new manual from scratch if
-they change the program, does not fill our community's needs.
-</p><p>
-While a blanket prohibition on modification is unacceptable, some
-kinds of limits on the method of modification pose no problem. For
-example, requirements to preserve the original author's copyright
-notice, the distribution terms, or the list of authors, are ok. It is
-also no problem to require modified versions to include notice that
-they were modified, even to have entire sections that may not be
-deleted or changed, as long as these sections deal with nontechnical
-topics. (Some GNU manuals have them.)
-</p><p>
-These kinds of restrictions are not a problem because, as a practical
-matter, they don't stop the conscientious programmer from adapting the
-manual to fit the modified program. In other words, they don't block
-the free software community from making full use of the manual.
-</p><p>
-However, it must be possible to modify all the <span class="emphasis"><em>technical</em></span>
-content of the manual, and then distribute the result in all the usual
-media, through all the usual channels; otherwise, the restrictions do
-block the community, the manual is not free, and so we need another
-manual.
-</p><p>
-Unfortunately, it is often hard to find someone to write another
-manual when a proprietary manual exists. The obstacle is that many
-users think that a proprietary manual is good enough--so they don't
-see the need to write a free manual. They do not see that the free
-operating system has a gap that needs filling.
-</p><p>
-Why do users think that proprietary manuals are good enough? Some
-have not considered the issue. I hope this article will do something
-to change that.
-</p><p>
-Other users consider proprietary manuals acceptable for the same
-reason so many people consider proprietary software acceptable: they
-judge in purely practical terms, not using freedom as a criterion.
-These people are entitled to their opinions, but since those opinions
-spring from values which do not include freedom, they are no guide for
-those of us who do value freedom.
-</p><p>
-Please spread the word about this issue. We continue to lose manuals
-to proprietary publishing. If we spread the word that proprietary
-manuals are not sufficient, perhaps the next person who wants to help
-GNU by writing documentation will realize, before it is too late, that
-he must above all make it free.
-</p><p>
-We can also encourage commercial publishers to sell free, copylefted
-manuals instead of proprietary ones. One way you can help this is to
-check the distribution terms of a manual before you buy it, and
-prefer copylefted manuals to non-copylefted ones.
-</p><p>
-[Note: We now maintain a <a class="ulink" href="http://www.fsf.org/licensing/doc/other-free-books.html" target="_top">web page
-that lists free books available from other publishers</a>].
-</p><p>Copyright © 2004, 2005, 2006, 2007 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA</p><p>Verbatim copying and distribution of this entire article are
-permitted worldwide, without royalty, in any medium, provided this
-notice is preserved.</p><p>Report any problems or suggestions to <code class="email">&lt;<a class="email" href="mailto:webmaster@fsf.org">webmaster@fsf.org</a>&gt;</code>.</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="backwards.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="appendix_gpl.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Backwards Compatibility </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix D. 
- GNU General Public License version 3
- </td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_gfdl.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_gfdl.html
deleted file mode 100644
index 1a6d54ef6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_gfdl.html
+++ /dev/null
@@ -1,395 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Appendix E. GNU Free Documentation License</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="appendix_gpl.html" title="Appendix D.  GNU General Public License version 3" /><link rel="next" href="bk01ix01.html" title="Index" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix E. GNU Free Documentation License</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="appendix_gpl.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="bk01ix01.html">Next</a></td></tr></table><hr /></div><div class="appendix" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="appendix.gfdl-1.2"></a>Appendix E. GNU Free Documentation License</h2></div></div></div><p>
- Copyright (C) 2000, 2001, 2002 Free Software Foundation,
- <abbr class="abbrev">Inc.</abbr> 51 Franklin <abbr class="abbrev">St</abbr>, Fifth Floor,
- Boston, <abbr class="abbrev">MA</abbr> 02110-1301 <abbr class="abbrev">USA</abbr>. Everyone is permitted to copy and
- distribute verbatim copies of this license document, but changing it is
- not allowed.
- </p><h2><a id="fdl-1-preamble"></a>
- 0. PREAMBLE
- </h2><p>
- The purpose of this License is to make a manual, textbook, or other
- functional and useful document "free" in the sense of freedom: to assure
- everyone the effective freedom to copy and redistribute it, with or
- without modifying it, either commercially or noncommercially.
- Secondarily, this License preserves for the author and publisher a way to
- get credit for their work, while not being considered responsible for
- modifications made by others.
- </p><p>
- This License is a kind of "copyleft", which means that derivative works of
- the document must themselves be free in the same sense. It complements
- the GNU General Public License, which is a copyleft license designed for
- free software.
- </p><p>
- We have designed this License in order to use it for manuals for free
- software, because free software needs free documentation: a free program
- should come with manuals providing the same freedoms that the software
- does. But this License is not limited to software manuals; it can be used
- for any textual work, regardless of subject matter or whether it is
- published as a printed book. We recommend this License principally for
- works whose purpose is instruction or reference.</p><h2><a id="fdl-1-definitions"></a>
- 1. APPLICABILITY AND DEFINITIONS
- </h2><p>
- This License applies to any manual or other work, in any medium, that
- contains a notice placed by the copyright holder saying it can be
- distributed under the terms of this License. Such a notice grants a
- world-wide, royalty-free license, unlimited in duration, to use that work
- under the conditions stated herein. The "Document", below, refers to any
- such manual or work. Any member of the public is a licensee, and is
- addressed as "you". You accept the license if you copy, modify or
- distribute the work in a way requiring permission under copyright
- law.
- </p><p>
- A "Modified Version" of the Document means any work containing the
- Document or a portion of it, either copied verbatim, or with modifications
- and/or translated into another language.
- </p><p>
- A "Secondary Section" is a named appendix or a front-matter section of the
- Document that deals exclusively with the relationship of the publishers or
- authors of the Document to the Document's overall subject (or to related
- matters) and contains nothing that could fall directly within that overall
- subject. (Thus, if the Document is in part a textbook of mathematics, a
- Secondary Section may not explain any mathematics.) The relationship
- could be a matter of historical connection with the subject or with
- related matters, or of legal, commercial, philosophical, ethical or
- political position regarding them.
- </p><p>
- The "Invariant Sections" are certain Secondary Sections whose titles are
- designated, as being those of Invariant Sections, in the notice that says
- that the Document is released under this License. If a section does not
- fit the above definition of Secondary then it is not allowed to be
- designated as Invariant. The Document may contain zero Invariant
- Sections. If the Document does not identify any Invariant Sections then
- there are none.
- </p><p>
- The "Cover Texts" are certain short passages of text that are listed, as
- Front-Cover Texts or Back-Cover Texts, in the notice that says that the
- Document is released under this License. A Front-Cover Text may be at
- most 5 words, and a Back-Cover Text may be at most 25 words.
- </p><p>
- A "Transparent" copy of the Document means a machine-readable copy,
- represented in a format whose specification is available to the general
- public, that is suitable for revising the document straightforwardly with
- generic text editors or (for images composed of pixels) generic paint
- programs or (for drawings) some widely available drawing editor, and that
- is suitable for input to text formatters or for automatic translation to a
- variety of formats suitable for input to text formatters. A copy made in
- an otherwise Transparent file format whose markup, or absence of markup,
- has been arranged to thwart or discourage subsequent modification by
- readers is not Transparent. An image format is not Transparent if used
- for any substantial amount of text. A copy that is not "Transparent" is
- called "Opaque".
- </p><p>
- Examples of suitable formats for Transparent copies include plain ASCII
- without markup, Texinfo input format, LaTeX input format, SGML or XML
- using a publicly available DTD, and standard-conforming simple HTML,
- PostScript or PDF designed for human modification. Examples of
- transparent image formats include PNG, XCF and JPG. Opaque formats
- include proprietary formats that can be read and edited only by
- proprietary word processors, SGML or XML for which the DTD and/or
- processing tools are not generally available, and the machine-generated
- HTML, PostScript or PDF produced by some word processors for output
- purposes only.
- </p><p>
- The "Title Page" means, for a printed book, the title page itself, plus
- such following pages as are needed to hold, legibly, the material this
- License requires to appear in the title page. For works in formats which
- do not have any title page as such, "Title Page" means the text near the
- most prominent appearance of the work's title, preceding the beginning of
- the body of the text.
- </p><p>
- A section "Entitled XYZ" means a named subunit of the Document whose title
- either is precisely XYZ or contains XYZ in parentheses following text that
- translates XYZ in another language. (Here XYZ stands for a specific
- section name mentioned below, such as "Acknowledgements", "Dedications",
- "Endorsements", or "History".) To "Preserve the Title" of such a section
- when you modify the Document means that it remains a section "Entitled
- XYZ" according to this definition.
- </p><p>
- The Document may include Warranty Disclaimers next to the notice which
- states that this License applies to the Document. These Warranty
- Disclaimers are considered to be included by reference in this License,
- but only as regards disclaiming warranties: any other implication that
- these Warranty Disclaimers may have is void and has no effect on the
- meaning of this License.
- </p><h2><a id="VerbatimCopying"></a>
- 2. VERBATIM COPYING
- </h2><p>
- You may copy and distribute the Document in any medium, either
- commercially or noncommercially, provided that this License, the copyright
- notices, and the license notice saying this License applies to the
- Document are reproduced in all copies, and that you add no other
- conditions whatsoever to those of this License. You may not use technical
- measures to obstruct or control the reading or further copying of the
- copies you make or distribute. However, you may accept compensation in
- exchange for copies. If you distribute a large enough number of copies
- you must also follow the conditions in section 3.
- </p><p>
- You may also lend copies, under the same conditions stated above, and you
- may publicly display copies.
- </p><h2><a id="QuantityCopying"></a>
- 3. COPYING IN QUANTITY
- </h2><p>
- If you publish printed copies (or copies in media that commonly have
- printed covers) of the Document, numbering more than 100, and the
- Document's license notice requires Cover Texts, you must enclose the
- copies in covers that carry, clearly and legibly, all these Cover Texts:
- Front-Cover Texts on the front cover, and Back-Cover Texts on the back
- cover. Both covers must also clearly and legibly identify you as the
- publisher of these copies. The front cover must present the full title
- with all words of the title equally prominent and visible. You may add
- other material on the covers in addition. Copying with changes limited to
- the covers, as long as they preserve the title of the Document and satisfy
- these conditions, can be treated as verbatim copying in other
- respects.
- </p><p>
- If the required texts for either cover are too voluminous to fit legibly,
- you should put the first ones listed (as many as fit reasonably) on the
- actual cover, and continue the rest onto adjacent pages.
- </p><p>
- If you publish or distribute Opaque copies of the Document numbering more
- than 100, you must either include a machine-readable Transparent copy
- along with each Opaque copy, or state in or with each Opaque copy a
- computer-network location from which the general network-using public has
- access to download using public-standard network protocols a complete
- Transparent copy of the Document, free of added material. If you use the
- latter option, you must take reasonably prudent steps, when you begin
- distribution of Opaque copies in quantity, to ensure that this Transparent
- copy will remain thus accessible at the stated location until at least one
- year after the last time you distribute an Opaque copy (directly or
- through your agents or retailers) of that edition to the public.
- </p><p>
- It is requested, but not required, that you contact the authors of the
- Document well before redistributing any large number of copies, to give
- them a chance to provide you with an updated version of the
- Document.
- </p><h2><a id="Modifications"></a>
- 4. MODIFICATIONS
- </h2><p>
- You may copy and distribute a Modified Version of the Document under the
- conditions of sections 2 and 3 above, provided that you release the
- Modified Version under precisely this License, with the Modified Version
- filling the role of the Document, thus licensing distribution and
- modification of the Modified Version to whoever possesses a copy of it.
- In addition, you must do these things in the Modified Version:
- </p><div class="orderedlist"><ol type="A"><li>
- Use in the Title Page (and on the covers, if any) a title distinct
- from that of the Document, and from those of previous versions (which
- should, if there were any, be listed in the History section of the
- Document). You may use the same title as a previous version if the
- original publisher of that version gives permission.
- </li><li>
- List on the Title Page, as authors, one or more persons or entities
- responsible for authorship of the modifications in the Modified
- Version, together with at least five of the principal authors of the
- Document (all of its principal authors, if it has fewer than five),
- unless they release you from this requirement.
- </li><li>
- State on the Title page the name of the publisher of the Modified
- Version, as the publisher.
- </li><li>
- Preserve all the copyright notices of the Document.
- </li><li>
- Add an appropriate copyright notice for your modifications adjacent to
- the other copyright notices.
- </li><li>
- Include, immediately after the copyright notices, a license notice
- giving the public permission to use the Modified Version under the
- terms of this License, in the form shown in the Addendum below.
- </li><li>
- Preserve in that license notice the full lists of Invariant Sections
- and required Cover Texts given in the Document's license notice.
- </li><li>
- Include an unaltered copy of this License.
- </li><li>
- Preserve the section Entitled "History", Preserve its Title, and add
- to it an item stating at least the title, year, new authors, and
- publisher of the Modified Version as given on the Title Page. If
- there is no section Entitled "History" in the Document, create one
- stating the title, year, authors, and publisher of the Document as
- given on its Title Page, then add an item describing the Modified
- Version as stated in the previous sentence.
- </li><li>
- Preserve the network location, if any, given in the Document for
- public access to a Transparent copy of the Document, and likewise the
- network locations given in the Document for previous versions it was
- based on. These may be placed in the "History" section. You may omit
- a network location for a work that was published at least four years
- before the Document itself, or if the original publisher of the
- version it refers to gives permission.
- </li><li>
- For any section Entitled "Acknowledgements" or "Dedications", Preserve
- the Title of the section, and preserve in the section all the
- substance and tone of each of the contributor acknowledgements and/or
- dedications given therein.
- </li><li>
- Preserve all the Invariant Sections of the Document, unaltered in
- their text and in their titles. Section numbers or the equivalent are
- not considered part of the section titles.
- </li><li>
- Delete any section Entitled "Endorsements". Such a section may not be
- included in the Modified Version.
- </li><li>
- Do not retitle any existing section to be Entitled "Endorsements" or
- to conflict in title with any Invariant Section.
- </li><li>
- Preserve any Warranty Disclaimers.
- </li></ol></div><p>
- If the Modified Version includes new front-matter sections or appendices
- that qualify as Secondary Sections and contain no material copied from the
- Document, you may at your option designate some or all of these sections
- as invariant. To do this, add their titles to the list of Invariant
- Sections in the Modified Version's license notice. These titles must be
- distinct from any other section titles.
- </p><p>
- You may add a section Entitled "Endorsements", provided it contains
- nothing but endorsements of your Modified Version by various parties--for
- example, statements of peer review or that the text has been approved by
- an organization as the authoritative definition of a standard.
- </p><p>
- You may add a passage of up to five words as a Front-Cover Text, and a
- passage of up to 25 words as a Back-Cover Text, to the end of the list of
- Cover Texts in the Modified Version. Only one passage of Front-Cover Text
- and one of Back-Cover Text may be added by (or through arrangements made
- by) any one entity. If the Document already includes a cover text for the
- same cover, previously added by you or by arrangement made by the same
- entity you are acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous publisher
- that added the old one.
- </p><p>
- The author(s) and publisher(s) of the Document do not by this License give
- permission to use their names for publicity for or to assert or imply
- endorsement of any Modified Version.
- </p><h2><a id="Combining"></a>
- 5. COMBINING DOCUMENTS
- </h2><p>
- You may combine the Document with other documents released under this
- License, under the terms defined in section 4 above for modified versions,
- provided that you include in the combination all of the Invariant Sections
- of all of the original documents, unmodified, and list them all as
- Invariant Sections of your combined work in its license notice, and that
- you preserve all their Warranty Disclaimers.
- </p><p>
- The combined work need only contain one copy of this License, and multiple
- identical Invariant Sections may be replaced with a single copy. If there
- are multiple Invariant Sections with the same name but different contents,
- make the title of each such section unique by adding at the end of it, in
- parentheses, the name of the original author or publisher of that section
- if known, or else a unique number. Make the same adjustment to the
- section titles in the list of Invariant Sections in the license notice of
- the combined work.
- </p><p>
- In the combination, you must combine any sections Entitled "History" in
- the various original documents, forming one section Entitled "History";
- likewise combine any sections Entitled "Acknowledgements", and any
- sections Entitled "Dedications". You must delete all sections Entitled
- "Endorsements".
- </p><h2><a id="Collections"></a>
- 6. COLLECTIONS OF DOCUMENTS
- </h2><p>
- You may make a collection consisting of the Document and other documents
- released under this License, and replace the individual copies of this
- License in the various documents with a single copy that is included in
- the collection, provided that you follow the rules of this License for
- verbatim copying of each of the documents in all other respects.
- </p><p>
- You may extract a single document from such a collection, and distribute
- it individually under this License, provided you insert a copy of this
- License into the extracted document, and follow this License in all other
- respects regarding verbatim copying of that document.
- </p><h2><a id="Aggregation"></a>
- 7. AGGREGATION WITH INDEPENDENT WORKS
- </h2><p>
- A compilation of the Document or its derivatives with other separate and
- independent documents or works, in or on a volume of a storage or
- distribution medium, is called an "aggregate" if the copyright resulting
- from the compilation is not used to limit the legal rights of the
- compilation's users beyond what the individual works permit. When the
- Document is included in an aggregate, this License does not apply to the
- other works in the aggregate which are not themselves derivative works of
- the Document.
- </p><p>
- If the Cover Text requirement of section 3 is applicable to these copies
- of the Document, then if the Document is less than one half of the entire
- aggregate, the Document's Cover Texts may be placed on covers that bracket
- the Document within the aggregate, or the electronic equivalent of covers
- if the Document is in electronic form. Otherwise they must appear on
- printed covers that bracket the whole aggregate.
- </p><h2><a id="Translation"></a>
- 8. TRANSLATION
- </h2><p>
- Translation is considered a kind of modification, so you may distribute
- translations of the Document under the terms of section 4. Replacing
- Invariant Sections with translations requires special permission from
- their copyright holders, but you may include translations of some or all
- Invariant Sections in addition to the original versions of these Invariant
- Sections. You may include a translation of this License, and all the
- license notices in the Document, and any Warranty Disclaimers, provided
- that you also include the original English version of this License and the
- original versions of those notices and disclaimers. In case of a
- disagreement between the translation and the original version of this
- License or a notice or disclaimer, the original version will prevail.
- </p><p>
- If a section in the Document is Entitled "Acknowledgements",
- "Dedications", or "History", the requirement (section 4) to Preserve its
- Title (section 1) will typically require changing the actual title.
- </p><h2><a id="fdl-1-termination"></a>
- 9. TERMINATION
- </h2><p>
- You may not copy, modify, sublicense, or distribute the Document except as
- expressly provided for under this License. Any other attempt to copy,
- modify, sublicense or distribute the Document is void, and will
- automatically terminate your rights under this License. However, parties
- who have received copies, or rights, from you under this License will not
- have their licenses terminated so long as such parties remain in full
- compliance.
- </p><h2><a id="FutureRevisions"></a>
- 10. FUTURE REVISIONS OF THIS LICENSE
- </h2><p>
- The Free Software Foundation may publish new, revised versions of the GNU
- Free Documentation License from time to time. Such new versions will be
- similar in spirit to the present version, but may differ in detail to
- address new problems or concerns. See <a class="ulink" href="http://www.gnu.org/copyleft/" target="_top">http://www.gnu.org/copyleft/</a>.
- </p><p>
- Each version of the License is given a distinguishing version number. If
- the Document specifies that a particular numbered version of this License
- "or any later version" applies to it, you have the option of following the
- terms and conditions either of that specified version or of any later
- version that has been published (not as a draft) by the Free Software
- Foundation. If the Document does not specify a version number of this
- License, you may choose any version ever published (not as a draft) by the
- Free Software Foundation.
- </p><h2><a id="HowToUse"></a>
- ADDENDUM: How to use this License for your documents
- </h2><p>
- To use this License in a document you have written, include a copy of the
- License in the document and put the following copyright and license
- notices just after the title page:
- </p><div class="blockquote"><blockquote class="blockquote"><p>
- Copyright (C) YEAR YOUR NAME.
- </p><p>
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.2 or
- any later version published by the Free Software Foundation; with no
- Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
- copy of the license is included in the section entitled "GNU Free
- Documentation License".
- </p></blockquote></div><p>
- If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
- replace the "with...Texts." line with this:
- </p><div class="blockquote"><blockquote class="blockquote"><p>
- with the Invariant Sections being LIST THEIR TITLES, with the
- Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
- </p></blockquote></div><p>
- If you have Invariant Sections without Cover Texts, or some other
- combination of the three, merge those two alternatives to suit the
- situation.
- </p><p>
- If your document contains nontrivial examples of program code, we
- recommend releasing these examples in parallel under your choice of free
- software license, such as the GNU General Public License, to permit their
- use in free software.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="appendix_gpl.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01ix01.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Appendix D. 
- GNU General Public License version 3
-  </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Index</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_gpl.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_gpl.html
deleted file mode 100644
index 7a4a57b18..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_gpl.html
+++ /dev/null
@@ -1,681 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Appendix D.  GNU General Public License version 3</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="appendix_free.html" title="Appendix C.  Free Software Needs Free Documentation" /><link rel="next" href="appendix_gfdl.html" title="Appendix E. GNU Free Documentation License" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix D. 
- GNU General Public License version 3
- </th></tr><tr><td width="20%" align="left"><a accesskey="p" href="appendix_free.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="appendix_gfdl.html">Next</a></td></tr></table><hr /></div><div class="appendix" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="appendix.gpl-3.0"></a>Appendix D. 
- <acronym class="acronym">GNU</acronym> General Public License version 3
- </h2></div></div></div><p>
- Version 3, 29 June 2007
- </p><p>
- Copyright © 2007 Free Software Foundation, Inc.
- <a class="ulink" href="http://fsf.org/" target="_top">http://fsf.org/</a>
- </p><p>
- Everyone is permitted to copy and distribute verbatim copies of this license
- document, but changing it is not allowed.
- </p><h2><a id="gpl-3-preamble"></a>
- Preamble
- </h2><p>
- The <acronym class="acronym">GNU</acronym> General Public License is a free, copyleft
- license for software and other kinds of works.
- </p><p>
- The licenses for most software and other practical works are designed to
- take away your freedom to share and change the works. By contrast, the
- <acronym class="acronym">GNU</acronym> General Public License is intended to guarantee your
- freedom to share and change all versions of a program—to make sure it
- remains free software for all its users. We, the Free Software Foundation,
- use the <acronym class="acronym">GNU</acronym> General Public License for most of our
- software; it applies also to any other work released this way by its
- authors. You can apply it to your programs, too.
- </p><p>
- When we speak of free software, we are referring to freedom, not price. Our
- General Public Licenses are designed to make sure that you have the freedom
- to distribute copies of free software (and charge for them if you wish),
- that you receive source code or can get it if you want it, that you can
- change the software or use pieces of it in new free programs, and that you
- know you can do these things.
- </p><p>
- To protect your rights, we need to prevent others from denying you these
- rights or asking you to surrender the rights. Therefore, you have certain
- responsibilities if you distribute copies of the software, or if you modify
- it: responsibilities to respect the freedom of others.
- </p><p>
- For example, if you distribute copies of such a program, whether gratis or
- for a fee, you must pass on to the recipients the same freedoms that you
- received. You must make sure that they, too, receive or can get the source
- code. And you must show them these terms so they know their rights.
- </p><p>
- Developers that use the <acronym class="acronym">GNU</acronym> <acronym class="acronym">GPL</acronym>
- protect your rights with two steps: (1) assert copyright on the software,
- and (2) offer you this License giving you legal permission to copy,
- distribute and/or modify it.
- </p><p>
- For the developers’ and authors’ protection, the
- <acronym class="acronym">GPL</acronym> clearly explains that there is no warranty for this
- free software. For both users’ and authors’ sake, the
- <acronym class="acronym">GPL</acronym> requires that modified versions be marked as changed,
- so that their problems will not be attributed erroneously to authors of
- previous versions.
- </p><p>
- Some devices are designed to deny users access to install or run modified
- versions of the software inside them, although the manufacturer can do so.
- This is fundamentally incompatible with the aim of protecting users’
- freedom to change the software. The systematic pattern of such abuse occurs
- in the area of products for individuals to use, which is precisely where it
- is most unacceptable. Therefore, we have designed this version of the
- <acronym class="acronym">GPL</acronym> to prohibit the practice for those products. If such
- problems arise substantially in other domains, we stand ready to extend this
- provision to those domains in future versions of the <acronym class="acronym">GPL</acronym>,
- as needed to protect the freedom of users.
- </p><p>
- Finally, every program is threatened constantly by software patents. States
- should not allow patents to restrict development and use of software on
- general-purpose computers, but in those that do, we wish to avoid the
- special danger that patents applied to a free program could make it
- effectively proprietary. To prevent this, the <acronym class="acronym">GPL</acronym>
- assures that patents cannot be used to render the program non-free.
- </p><p>
- The precise terms and conditions for copying, distribution and modification
- follow.
- </p><h2><a id="id518323"></a>
- TERMS AND CONDITIONS
- </h2><h2><a id="gpl-3-definitions"></a>
- 0. Definitions.
- </h2><p>
- “This License” refers to version 3 of the <acronym class="acronym">GNU</acronym>
- General Public License.
- </p><p>
- “Copyright” also means copyright-like laws that apply to other
- kinds of works, such as semiconductor masks.
- </p><p>
- “The Program” refers to any copyrightable work licensed under
- this License. Each licensee is addressed as “you”.
- “Licensees” and “recipients” may be individuals or
- organizations.
- </p><p>
- To “modify” a work means to copy from or adapt all or part of
- the work in a fashion requiring copyright permission, other than the making
- of an exact copy. The resulting work is called a “modified
- version” of the earlier work or a work “based on” the
- earlier work.
- </p><p>
- A “covered work” means either the unmodified Program or a work
- based on the Program.
- </p><p>
- To “propagate” a work means to do anything with it that, without
- permission, would make you directly or secondarily liable for infringement
- under applicable copyright law, except executing it on a computer or
- modifying a private copy. Propagation includes copying, distribution (with
- or without modification), making available to the public, and in some
- countries other activities as well.
- </p><p>
- To “convey” a work means any kind of propagation that enables
- other parties to make or receive copies. Mere interaction with a user
- through a computer network, with no transfer of a copy, is not conveying.
- </p><p>
- An interactive user interface displays “Appropriate Legal
- Notices” to the extent that it includes a convenient and prominently
- visible feature that (1) displays an appropriate copyright notice, and (2)
- tells the user that there is no warranty for the work (except to the extent
- that warranties are provided), that licensees may convey the work under this
- License, and how to view a copy of this License. If the interface presents
- a list of user commands or options, such as a menu, a prominent item in the
- list meets this criterion.
- </p><h2><a id="SourceCode"></a>
- 1. Source Code.
- </h2><p>
- The “source code” for a work means the preferred form of the
- work for making modifications to it. “Object code” means any
- non-source form of a work.
- </p><p>
- A “Standard Interface” means an interface that either is an
- official standard defined by a recognized standards body, or, in the case of
- interfaces specified for a particular programming language, one that is
- widely used among developers working in that language.
- </p><p>
- The “System Libraries” of an executable work include anything,
- other than the work as a whole, that (a) is included in the normal form of
- packaging a Major Component, but which is not part of that Major Component,
- and (b) serves only to enable use of the work with that Major Component, or
- to implement a Standard Interface for which an implementation is available
- to the public in source code form. A “Major Component”, in this
- context, means a major essential component (kernel, window system, and so
- on) of the specific operating system (if any) on which the executable work
- runs, or a compiler used to produce the work, or an object code interpreter
- used to run it.
- </p><p>
- The “Corresponding Source” for a work in object code form means
- all the source code needed to generate, install, and (for an executable
- work) run the object code and to modify the work, including scripts to
- control those activities. However, it does not include the work’s
- System Libraries, or general-purpose tools or generally available free
- programs which are used unmodified in performing those activities but which
- are not part of the work. For example, Corresponding Source includes
- interface definition files associated with source files for the work, and
- the source code for shared libraries and dynamically linked subprograms that
- the work is specifically designed to require, such as by intimate data
- communication or control flow between those subprograms and other parts of
- the work.
- </p><p>
- The Corresponding Source need not include anything that users can regenerate
- automatically from other parts of the Corresponding Source.
- </p><p>
- The Corresponding Source for a work in source code form is that same work.
- </p><h2><a id="BasicPermissions"></a>
- 2. Basic Permissions.
- </h2><p>
- All rights granted under this License are granted for the term of copyright
- on the Program, and are irrevocable provided the stated conditions are met.
- This License explicitly affirms your unlimited permission to run the
- unmodified Program. The output from running a covered work is covered by
- this License only if the output, given its content, constitutes a covered
- work. This License acknowledges your rights of fair use or other
- equivalent, as provided by copyright law.
- </p><p>
- You may make, run and propagate covered works that you do not convey,
- without conditions so long as your license otherwise remains in force. You
- may convey covered works to others for the sole purpose of having them make
- modifications exclusively for you, or provide you with facilities for
- running those works, provided that you comply with the terms of this License
- in conveying all material for which you do not control copyright. Those
- thus making or running the covered works for you must do so exclusively on
- your behalf, under your direction and control, on terms that prohibit them
- from making any copies of your copyrighted material outside their
- relationship with you.
- </p><p>
- Conveying under any other circumstances is permitted solely under the
- conditions stated below. Sublicensing is not allowed; section 10 makes it
- unnecessary.
- </p><h2><a id="Protecting"></a>
- 3. Protecting Users’ Legal Rights From Anti-Circumvention Law.
- </h2><p>
- No covered work shall be deemed part of an effective technological measure
- under any applicable law fulfilling obligations under article 11 of the WIPO
- copyright treaty adopted on 20 December 1996, or similar laws prohibiting or
- restricting circumvention of such measures.
- </p><p>
- When you convey a covered work, you waive any legal power to forbid
- circumvention of technological measures to the extent such circumvention is
- effected by exercising rights under this License with respect to the covered
- work, and you disclaim any intention to limit operation or modification of
- the work as a means of enforcing, against the work’s users, your or
- third parties’ legal rights to forbid circumvention of technological
- measures.
- </p><h2><a id="ConveyingVerbatim"></a>
- 4. Conveying Verbatim Copies.
- </h2><p>
- You may convey verbatim copies of the Program’s source code as you
- receive it, in any medium, provided that you conspicuously and appropriately
- publish on each copy an appropriate copyright notice; keep intact all
- notices stating that this License and any non-permissive terms added in
- accord with section 7 apply to the code; keep intact all notices of the
- absence of any warranty; and give all recipients a copy of this License
- along with the Program.
- </p><p>
- You may charge any price or no price for each copy that you convey, and you
- may offer support or warranty protection for a fee.
- </p><h2><a id="ConveyingModified"></a>
- 5. Conveying Modified Source Versions.
- </h2><p>
- You may convey a work based on the Program, or the modifications to produce
- it from the Program, in the form of source code under the terms of section
- 4, provided that you also meet all of these conditions:
- </p><div class="orderedlist"><ol type="a"><li><p>
- The work must carry prominent notices stating that you modified it, and
- giving a relevant date.
- </p></li><li><p>
- The work must carry prominent notices stating that it is released under
- this License and any conditions added under section 7. This requirement
- modifies the requirement in section 4 to “keep intact all
- notices”.
- </p></li><li><p>
- You must license the entire work, as a whole, under this License to
- anyone who comes into possession of a copy. This License will therefore
- apply, along with any applicable section 7 additional terms, to the
- whole of the work, and all its parts, regardless of how they are
- packaged. This License gives no permission to license the work in any
- other way, but it does not invalidate such permission if you have
- separately received it.
- </p></li><li><p>
- If the work has interactive user interfaces, each must display
- Appropriate Legal Notices; however, if the Program has interactive
- interfaces that do not display Appropriate Legal Notices, your work need
- not make them do so.
- </p></li></ol></div><p>
- A compilation of a covered work with other separate and independent works,
- which are not by their nature extensions of the covered work, and which are
- not combined with it such as to form a larger program, in or on a volume of
- a storage or distribution medium, is called an “aggregate” if
- the compilation and its resulting copyright are not used to limit the access
- or legal rights of the compilation’s users beyond what the individual works
- permit. Inclusion of a covered work in an aggregate does not cause
- this License to apply to the other parts of the aggregate.
- </p><h2><a id="ConveyingNonSource"></a>
- 6. Conveying Non-Source Forms.
- </h2><p>
- You may convey a covered work in object code form under the terms of
- sections 4 and 5, provided that you also convey the machine-readable
- Corresponding Source under the terms of this License, in one of these ways:
- </p><div class="orderedlist"><ol type="a"><li><p>
- Convey the object code in, or embodied in, a physical product (including
- a physical distribution medium), accompanied by the Corresponding Source
- fixed on a durable physical medium customarily used for software
- interchange.
- </p></li><li><p>
- Convey the object code in, or embodied in, a physical product (including
- a physical distribution medium), accompanied by a written offer, valid
- for at least three years and valid for as long as you offer spare parts
- or customer support for that product model, to give anyone who possesses
- the object code either (1) a copy of the Corresponding Source for all
- the software in the product that is covered by this License, on a
- durable physical medium customarily used for software interchange, for a
- price no more than your reasonable cost of physically performing this
- conveying of source, or (2) access to copy the Corresponding Source from
- a network server at no charge.
- </p></li><li><p>
- Convey individual copies of the object code with a copy of the written
- offer to provide the Corresponding Source. This alternative is allowed
- only occasionally and noncommercially, and only if you received the
- object code with such an offer, in accord with subsection 6b.
- </p></li><li><p>
- Convey the object code by offering access from a designated place
- (gratis or for a charge), and offer equivalent access to the
- Corresponding Source in the same way through the same place at no
- further charge. You need not require recipients to copy the
- Corresponding Source along with the object code. If the place to copy
- the object code is a network server, the Corresponding Source may be on
- a different server (operated by you or a third party) that supports
- equivalent copying facilities, provided you maintain clear directions
- next to the object code saying where to find the Corresponding Source.
- Regardless of what server hosts the Corresponding Source, you remain
- obligated to ensure that it is available for as long as needed to
- satisfy these requirements.
- </p></li><li><p>
- Convey the object code using peer-to-peer transmission, provided you
- inform other peers where the object code and Corresponding Source of the
- work are being offered to the general public at no charge under
- subsection 6d.
- </p></li></ol></div><p>
- A separable portion of the object code, whose source code is excluded from
- the Corresponding Source as a System Library, need not be included in
- conveying the object code work.
- </p><p>
- A “User Product” is either (1) a “consumer product”,
- which means any tangible personal property which is normally used for
- personal, family, or household purposes, or (2) anything designed or sold
- for incorporation into a dwelling. In determining whether a product is a
- consumer product, doubtful cases shall be resolved in favor of coverage.
- For a particular product received by a particular user, “normally
- used” refers to a typical or common use of that class of product,
- regardless of the status of the particular user or of the way in which the
- particular user actually uses, or expects or is expected to use, the
- product. A product is a consumer product regardless of whether the product
- has substantial commercial, industrial or non-consumer uses, unless such
- uses represent the only significant mode of use of the product.
- </p><p>
- “Installation Information” for a User Product means any methods,
- procedures, authorization keys, or other information required to install and
- execute modified versions of a covered work in that User Product from a
- modified version of its Corresponding Source. The information must suffice
- to ensure that the continued functioning of the modified object code is in
- no case prevented or interfered with solely because modification has been
- made.
- </p><p>
- If you convey an object code work under this section in, or with, or
- specifically for use in, a User Product, and the conveying occurs as part of
- a transaction in which the right of possession and use of the User Product
- is transferred to the recipient in perpetuity or for a fixed term
- (regardless of how the transaction is characterized), the Corresponding
- Source conveyed under this section must be accompanied by the Installation
- Information. But this requirement does not apply if neither you nor any
- third party retains the ability to install modified object code on the User
- Product (for example, the work has been installed in
- <acronym class="acronym">ROM</acronym>).
- </p><p>
- The requirement to provide Installation Information does not include a
- requirement to continue to provide support service, warranty, or updates for
- a work that has been modified or installed by the recipient, or for the User
- Product in which it has been modified or installed. Access to a network may
- be denied when the modification itself materially and adversely affects the
- operation of the network or violates the rules and protocols for
- communication across the network.
- </p><p>
- Corresponding Source conveyed, and Installation Information provided, in
- accord with this section must be in a format that is publicly documented
- (and with an implementation available to the public in source code form),
- and must require no special password or key for unpacking, reading or
- copying.
- </p><h2><a id="AdditionalTerms"></a>
- 7. Additional Terms.
- </h2><p>
- “Additional permissions” are terms that supplement the terms of
- this License by making exceptions from one or more of its conditions.
- Additional permissions that are applicable to the entire Program shall be
- treated as though they were included in this License, to the extent that
- they are valid under applicable law. If additional permissions apply only
- to part of the Program, that part may be used separately under those
- permissions, but the entire Program remains governed by this License
- without regard to the additional permissions.
- </p><p>
- When you convey a copy of a covered work, you may at your option remove any
- additional permissions from that copy, or from any part of it. (Additional
- permissions may be written to require their own removal in certain cases
- when you modify the work.) You may place additional permissions on
- material, added by you to a covered work, for which you have or can give
- appropriate copyright permission.
- </p><p>
- Notwithstanding any other provision of this License, for material you add
- to a covered work, you may (if authorized by the copyright holders of that
- material) supplement the terms of this License with terms:
- </p><div class="orderedlist"><ol type="a"><li><p>
- Disclaiming warranty or limiting liability differently from the terms
- of sections 15 and 16 of this License; or
- </p></li><li><p>
- Requiring preservation of specified reasonable legal notices or author
- attributions in that material or in the Appropriate Legal Notices
- displayed by works containing it; or
- </p></li><li><p>
- Prohibiting misrepresentation of the origin of that material, or
- requiring that modified versions of such material be marked in
- reasonable ways as different from the original version; or
- </p></li><li><p>
- Limiting the use for publicity purposes of names of licensors or
- authors of the material; or
- </p></li><li><p>
- Declining to grant rights under trademark law for use of some trade
- names, trademarks, or service marks; or
- </p></li><li><p>
- Requiring indemnification of licensors and authors of that material by
- anyone who conveys the material (or modified versions of it) with
- contractual assumptions of liability to the recipient, for any
- liability that these contractual assumptions directly impose on those
- licensors and authors.
- </p></li></ol></div><p>
- All other non-permissive additional terms are considered “further
- restrictions” within the meaning of section 10. If the Program as
- you received it, or any part of it, contains a notice stating that it is
- governed by this License along with a term that is a further restriction,
- you may remove that term. If a license document contains a further
- restriction but permits relicensing or conveying under this License, you
- may add to a covered work material governed by the terms of that license
- document, provided that the further restriction does not survive such
- relicensing or conveying.
- </p><p>
- If you add terms to a covered work in accord with this section, you must
- place, in the relevant source files, a statement of the additional terms
- that apply to those files, or a notice indicating where to find the
- applicable terms.
- </p><p>
- Additional terms, permissive or non-permissive, may be stated in the form
- of a separately written license, or stated as exceptions; the above
- requirements apply either way.
- </p><h2><a id="gpl-3-termination"></a>
- 8. Termination.
- </h2><p>
- You may not propagate or modify a covered work except as expressly provided
- under this License. Any attempt otherwise to propagate or modify it is
- void, and will automatically terminate your rights under this License
- (including any patent licenses granted under the third paragraph of section
- 11).
- </p><p>
- However, if you cease all violation of this License, then your license from
- a particular copyright holder is reinstated (a) provisionally, unless and
- until the copyright holder explicitly and finally terminates your license,
- and (b) permanently, if the copyright holder fails to notify you of the
- violation by some reasonable means prior to 60 days after the cessation.
- </p><p>
- Moreover, your license from a particular copyright holder is reinstated
- permanently if the copyright holder notifies you of the violation by some
- reasonable means, this is the first time you have received notice of
- violation of this License (for any work) from that copyright holder, and
- you cure the violation prior to 30 days after your receipt of the notice.
- </p><p>
- Termination of your rights under this section does not terminate the
- licenses of parties who have received copies or rights from you under this
- License. If your rights have been terminated and not permanently
- reinstated, you do not qualify to receive new licenses for the same
- material under section 10.
- </p><h2><a id="AcceptanceNotRequired"></a>
- 9. Acceptance Not Required for Having Copies.
- </h2><p>
- You are not required to accept this License in order to receive or run a
- copy of the Program. Ancillary propagation of a covered work occurring
- solely as a consequence of using peer-to-peer transmission to receive a
- copy likewise does not require acceptance. However, nothing other than
- this License grants you permission to propagate or modify any covered work.
- These actions infringe copyright if you do not accept this License.
- Therefore, by modifying or propagating a covered work, you indicate your
- acceptance of this License to do so.
- </p><h2><a id="AutomaticDownstream"></a>
- 10. Automatic Licensing of Downstream Recipients.
- </h2><p>
- Each time you convey a covered work, the recipient automatically receives a
- license from the original licensors, to run, modify and propagate that
- work, subject to this License. You are not responsible for enforcing
- compliance by third parties with this License.
- </p><p>
- An “entity transaction” is a transaction transferring control
- of an organization, or substantially all assets of one, or subdividing an
- organization, or merging organizations. If propagation of a covered work
- results from an entity transaction, each party to that transaction who
- receives a copy of the work also receives whatever licenses to the work the
- party’s predecessor in interest had or could give under the previous
- paragraph, plus a right to possession of the Corresponding Source of the
- work from the predecessor in interest, if the predecessor has it or can get
- it with reasonable efforts.
- </p><p>
- You may not impose any further restrictions on the exercise of the rights
- granted or affirmed under this License. For example, you may not impose a
- license fee, royalty, or other charge for exercise of rights granted under
- this License, and you may not initiate litigation (including a cross-claim
- or counterclaim in a lawsuit) alleging that any patent claim is infringed
- by making, using, selling, offering for sale, or importing the Program or
- any portion of it.
- </p><h2><a id="Patents"></a>
- 11. Patents.
- </h2><p>
- A “contributor” is a copyright holder who authorizes use under
- this License of the Program or a work on which the Program is based. The
- work thus licensed is called the contributor’s “contributor
- version”.
- </p><p>
- A contributor’s “essential patent claims” are all patent
- claims owned or controlled by the contributor, whether already acquired or
- hereafter acquired, that would be infringed by some manner, permitted by
- this License, of making, using, or selling its contributor version, but do
- not include claims that would be infringed only as a consequence of further
- modification of the contributor version. For purposes of this definition,
- “control” includes the right to grant patent sublicenses in a
- manner consistent with the requirements of this License.
- </p><p>
- Each contributor grants you a non-exclusive, worldwide, royalty-free patent
- license under the contributor’s essential patent claims, to make, use,
- sell, offer for sale, import and otherwise run, modify and propagate the
- contents of its contributor version.
- </p><p>
- In the following three paragraphs, a “patent license” is any
- express agreement or commitment, however denominated, not to enforce a
- patent (such as an express permission to practice a patent or covenant not
- to sue for patent infringement). To “grant” such a patent
- license to a party means to make such an agreement or commitment not to
- enforce a patent against the party.
- </p><p>
- If you convey a covered work, knowingly relying on a patent license, and the
- Corresponding Source of the work is not available for anyone to copy, free
- of charge and under the terms of this License, through a publicly available
- network server or other readily accessible means, then you must either (1)
- cause the Corresponding Source to be so available, or (2) arrange to deprive
- yourself of the benefit of the patent license for this particular work, or
- (3) arrange, in a manner consistent with the requirements of this License,
- to extend the patent license to downstream recipients. “Knowingly
- relying” means you have actual knowledge that, but for the patent
- license, your conveying the covered work in a country, or your
- recipient’s use of the covered work in a country, would infringe one
- or more identifiable patents in that country that you have reason to believe
- are valid.
- </p><p>
- If, pursuant to or in connection with a single transaction or arrangement,
- you convey, or propagate by procuring conveyance of, a covered work, and
- grant a patent license to some of the parties receiving the covered work
- authorizing them to use, propagate, modify or convey a specific copy of the
- covered work, then the patent license you grant is automatically extended to
- all recipients of the covered work and works based on it.
- </p><p>
- A patent license is “discriminatory” if it does not include
- within the scope of its coverage, prohibits the exercise of, or is
- conditioned on the non-exercise of one or more of the rights that are
- specifically granted under this License. You may not convey a covered work
- if you are a party to an arrangement with a third party that is in the
- business of distributing software, under which you make payment to the third
- party based on the extent of your activity of conveying the work, and under
- which the third party grants, to any of the parties who would receive the
- covered work from you, a discriminatory patent license (a) in connection
- with copies of the covered work conveyed by you (or copies made from those
- copies), or (b) primarily for and in connection with specific products or
- compilations that contain the covered work, unless you entered into that
- arrangement, or that patent license was granted, prior to 28 March 2007.
- </p><p>
- Nothing in this License shall be construed as excluding or limiting any
- implied license or other defenses to infringement that may otherwise be
- available to you under applicable patent law.
- </p><h2><a id="NoSurrender"></a>
- 12. No Surrender of Others’ Freedom.
- </h2><p>
- If conditions are imposed on you (whether by court order, agreement or
- otherwise) that contradict the conditions of this License, they do not
- excuse you from the conditions of this License. If you cannot convey a
- covered work so as to satisfy simultaneously your obligations under this
- License and any other pertinent obligations, then as a consequence you may
- not convey it at all. For example, if you agree to terms that obligate you
- to collect a royalty for further conveying from those to whom you convey the
- Program, the only way you could satisfy both those terms and this License
- would be to refrain entirely from conveying the Program.
- </p><h2><a id="UsedWithAGPL"></a>
- 13. Use with the <acronym class="acronym">GNU</acronym> Affero General Public License.
- </h2><p>
- Notwithstanding any other provision of this License, you have permission to
- link or combine any covered work with a work licensed under version 3 of the
- <acronym class="acronym">GNU</acronym> Affero General Public License into a single combined
- work, and to convey the resulting work. The terms of this License will
- continue to apply to the part which is the covered work, but the special
- requirements of the <acronym class="acronym">GNU</acronym> Affero General Public License,
- section 13, concerning interaction through a network will apply to the
- combination as such.
- </p><h2><a id="RevisedVersions"></a>
- 14. Revised Versions of this License.
- </h2><p>
- The Free Software Foundation may publish revised and/or new versions of the
- <acronym class="acronym">GNU</acronym> General Public License from time to time. Such new
- versions will be similar in spirit to the present version, but may differ in
- detail to address new problems or concerns.
- </p><p>
- Each version is given a distinguishing version number. If the Program
- specifies that a certain numbered version of the <acronym class="acronym">GNU</acronym>
- General Public License “or any later version” applies to it, you
- have the option of following the terms and conditions either of that
- numbered version or of any later version published by the Free Software
- Foundation. If the Program does not specify a version number of the
- <acronym class="acronym">GNU</acronym> General Public License, you may choose any version
- ever published by the Free Software Foundation.
- </p><p>
- If the Program specifies that a proxy can decide which future versions of
- the <acronym class="acronym">GNU</acronym> General Public License can be used, that
- proxy’s public statement of acceptance of a version permanently
- authorizes you to choose that version for the Program.
- </p><p>
- Later license versions may give you additional or different permissions.
- However, no additional obligations are imposed on any author or copyright
- holder as a result of your choosing to follow a later version.
- </p><h2><a id="WarrantyDisclaimer"></a>
- 15. Disclaimer of Warranty.
- </h2><p>
- THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
- LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
- OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF
- ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH
- YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
- NECESSARY SERVICING, REPAIR OR CORRECTION.
- </p><h2><a id="LiabilityLimitation"></a>
- 16. Limitation of Liability.
- </h2><p>
- IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL
- ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE
- PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
- GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE
- OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA
- OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
- PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
- EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
- SUCH DAMAGES.
- </p><h2><a id="InterpretationSecs1516"></a>
- 17. Interpretation of Sections 15 and 16.
- </h2><p>
- If the disclaimer of warranty and limitation of liability provided above
- cannot be given local legal effect according to their terms, reviewing
- courts shall apply local law that most closely approximates an absolute
- waiver of all civil liability in connection with the Program, unless a
- warranty or assumption of liability accompanies a copy of the Program in
- return for a fee.
- </p><h2><a id="id387622"></a>
- END OF TERMS AND CONDITIONS
- </h2><h2><a id="HowToApply"></a>
- How to Apply These Terms to Your New Programs
- </h2><p>
- If you develop a new program, and you want it to be of the greatest possible
- use to the public, the best way to achieve this is to make it free software
- which everyone can redistribute and change under these terms.
- </p><p>
- To do so, attach the following notices to the program. It is safest to
- attach them to the start of each source file to most effectively state the
- exclusion of warranty; and each file should have at least the
- “copyright” line and a pointer to where the full notice is
- found.
- </p><pre class="screen">
-<em class="replaceable"><code>one line to give the program’s name and a brief idea of what it does.</code></em>
-Copyright (C) <em class="replaceable"><code>year</code></em> <em class="replaceable"><code>name of author</code></em>
-
-This program is free software: you can redistribute it and/or modify
-it under the terms of the <acronym class="acronym">GNU</acronym> General Public License as published by
-the Free Software Foundation, either version 3 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-<acronym class="acronym">GNU</acronym> General Public License for more details.
-
-You should have received a copy of the <acronym class="acronym">GNU</acronym> General Public License
-along with this program. If not, see <a class="ulink" href="http://www.gnu.org/licenses/" target="_top">http://www.gnu.org/licenses/</a>.
- </pre><p>
- Also add information on how to contact you by electronic and paper mail.
- </p><p>
- If the program does terminal interaction, make it output a short notice like
- this when it starts in an interactive mode:
- </p><pre class="screen">
-<em class="replaceable"><code>program</code></em> Copyright (C) <em class="replaceable"><code>year</code></em> <em class="replaceable"><code>name of author</code></em>
-This program comes with ABSOLUTELY NO WARRANTY; for details type ‘<code class="literal">show w</code>’.
-This is free software, and you are welcome to redistribute it
-under certain conditions; type ‘<code class="literal">show c</code>’ for details.
- </pre><p>
- The hypothetical commands ‘<code class="literal">show w</code>’ and
- ‘<code class="literal">show c</code>’ should show the appropriate parts of
- the General Public License. Of course, your program’s commands might be
- different; for a GUI interface, you would use an “about box”.
- </p><p>
- You should also get your employer (if you work as a programmer) or school,
- if any, to sign a “copyright disclaimer” for the program, if
- necessary. For more information on this, and how to apply and follow the
- <acronym class="acronym">GNU</acronym> <acronym class="acronym">GPL</acronym>, see
- <a class="ulink" href="http://www.gnu.org/licenses/" target="_top">http://www.gnu.org/licenses/</a>.
- </p><p>
- The <acronym class="acronym">GNU</acronym> General Public License does not permit
- incorporating your program into proprietary programs. If your program is a
- subroutine library, you may consider it more useful to permit linking
- proprietary applications with the library. If this is what you want to do,
- use the <acronym class="acronym">GNU</acronym> Lesser General Public License instead of this
- License. But first, please read <a class="ulink" href="http://www.gnu.org/philosophy/why-not-lgpl.html" target="_top">http://www.gnu.org/philosophy/why-not-lgpl.html</a>.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="appendix_free.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="appendix_gfdl.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Appendix C. 
- Free Software Needs Free Documentation
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix E. GNU Free Documentation License</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_porting.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_porting.html
deleted file mode 100644
index fb73ccab9..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/appendix_porting.html
+++ /dev/null
@@ -1,230 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Appendix B.  Porting and Maintenance</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="source_design_notes.html" title="Design Notes" /><link rel="next" href="internals.html" title="Porting to New Hardware or Operating Systems" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix B. 
- Porting and Maintenance
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="source_design_notes.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="internals.html">Next</a></td></tr></table><hr /></div><div class="appendix" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="appendix.porting"></a>Appendix B. 
- Porting and Maintenance
- <a id="id517404" class="indexterm"></a>
-</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="appendix_porting.html#appendix.porting.build_hacking">Configure and Build Hacking</a></span></dt><dd><dl><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.prereq">Prerequisites</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.map">Overview: What Comes from Where</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.scripts">Storing Information in non-AC files (like configure.host)</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.conventions">Coding and Commenting Conventions</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.acinclude">The acinclude.m4 layout</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.enable">GLIBCXX_ENABLE, the --enable maker</a></span></dt></dl></dd><dt><span class="sect1"><a href="internals.html">Porting to New Hardware or Operating Systems</a></span></dt><dd><dl><dt><span class="sect2"><a href="internals.html#internals.os">Operating System</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.cpu">CPU</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.char_types">Character Types</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.thread_safety">Thread Safety</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.numeric_limits">Numeric Limits</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.libtool">Libtool</a></span></dt></dl></dd><dt><span class="sect1"><a href="abi.html">ABI Policy and Guidelines</a></span></dt><dd><dl><dt><span class="sect2"><a href="abi.html#abi.cxx_interface">The C++ Interface</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.versioning">Versioning</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.changes_allowed">Allowed Changes</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.changes_no">Prohibited Changes</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.testing">Testing</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.issues">Outstanding Issues</a></span></dt></dl></dd><dt><span class="sect1"><a href="api.html">API Evolution and Deprecation History</a></span></dt><dd><dl><dt><span class="sect2"><a href="api.html#api.rel_300">3.0</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_310">3.1</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_320">3.2</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_330">3.3</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_340">3.4</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_400">4.0</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_410">4.1</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_420">4.2</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_430">4.3</a></span></dt></dl></dd><dt><span class="sect1"><a href="backwards.html">Backwards Compatibility</a></span></dt><dd><dl><dt><span class="sect2"><a href="backwards.html#backwards.first">First</a></span></dt><dt><span class="sect2"><a href="backwards.html#backwards.second">Second</a></span></dt><dt><span class="sect2"><a href="backwards.html#backwards.third">Third</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="appendix.porting.build_hacking"></a>Configure and Build Hacking</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="build_hacking.prereq"></a>Prerequisites</h3></div></div></div><p>
- As noted <a class="ulink" href="http://gcc.gnu.org/install/prerequisites.html" target="_top">previously</a>,
- certain other tools are necessary for hacking on files that
- control configure (<code class="code">configure.ac</code>,
- <code class="code">acinclude.m4</code>) and make
- (<code class="code">Makefile.am</code>). These additional tools
- (<code class="code">automake</code>, and <code class="code">autoconf</code>) are further
- described in detail in their respective manuals. All the libraries
- in GCC try to stay in sync with each other in terms of versions of
- the auto-tools used, so please try to play nicely with the
- neighbors.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="build_hacking.map"></a>Overview: What Comes from Where</h3></div></div></div><pre class="screen">
- <img src="../images/confdeps.png" alt="Dependency Graph Configure to Build Files" />
- </pre><p>
- Regenerate all generated files by using the command sequence
- <code class="code">"autoreconf"</code> at the top level of the libstdc++ source
- directory. The following will also work, but is much more complex:
- <code class="code">"aclocal-1.7 &amp;&amp; autoconf-2.59 &amp;&amp;
- autoheader-2.59 &amp;&amp; automake-1.7"</code> The version
- numbers may be absent entirely or otherwise vary depending on
- <a class="ulink" href="http://gcc.gnu.org/install/prerequisites.html" target="_top">the
- current requirements</a> and your vendor's choice of
- installation names.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="build_hacking.scripts"></a>Storing Information in non-AC files (like configure.host)</h3></div></div></div><p>
- Until that glorious day when we can use AC_TRY_LINK with a
- cross-compiler, we have to hardcode the results of what the tests
- would have shown if they could be run. So we have an inflexible
- mess like crossconfig.m4.
- </p><p>
- Wouldn't it be nice if we could store that information in files
- like configure.host, which can be modified without needing to
- regenerate anything, and can even be tweaked without really
- knowing how the configury all works? Perhaps break the pieces of
- crossconfig.m4 out and place them in their appropriate
- config/{cpu,os} directory.
- </p><p>
- Alas, writing macros like
- "<code class="code">AC_DEFINE(HAVE_A_NICE_DAY)</code>" can only be done inside
- files which are passed through autoconf. Files which are pure
- shell script can be source'd at configure time. Files which
- contain autoconf macros must be processed with autoconf. We could
- still try breaking the pieces out into "config/*/cross.m4" bits,
- for instance, but then we would need arguments to aclocal/autoconf
- to properly find them all when generating configure. I would
- discourage that.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="build_hacking.conventions"></a>Coding and Commenting Conventions</h3></div></div></div><p>
- Most comments should use {octothorpes, shibboleths, hash marks,
- pound signs, whatever} rather than "dnl". Nearly all comments in
- configure.ac should. Comments inside macros written in ancilliary
- .m4 files should. About the only comments which should
- <span class="emphasis"><em>not</em></span> use #, but use dnl instead, are comments
- <span class="emphasis"><em>outside</em></span> our own macros in the ancilliary
- files. The difference is that # comments show up in
- <code class="code">configure</code> (which is most helpful for debugging),
- while dnl'd lines just vanish. Since the macros in ancilliary
- files generate code which appears in odd places, their "outside"
- comments tend to not be useful while reading
- <code class="code">configure</code>.
- </p><p>
- Do not use any <code class="code">$target*</code> variables, such as
- <code class="code">$target_alias</code>. The single exception is in
- configure.ac, for automake+dejagnu's sake.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="build_hacking.acinclude"></a>The acinclude.m4 layout</h3></div></div></div><p>
- The nice thing about acinclude.m4/aclocal.m4 is that macros aren't
- actually performed/called/expanded/whatever here, just loaded. So
- we can arrange the contents however we like. As of this writing,
- acinclude.m4 is arranged as follows:
- </p><pre class="programlisting">
- GLIBCXX_CHECK_HOST
- GLIBCXX_TOPREL_CONFIGURE
- GLIBCXX_CONFIGURE
- </pre><p>
- All the major variable "discovery" is done here. CXX, multilibs,
- etc.
- </p><pre class="programlisting">
- fragments included from elsewhere
- </pre><p>
- Right now, "fragments" == "the math/linkage bits".
- </p><pre class="programlisting">
- GLIBCXX_CHECK_COMPILER_FEATURES
- GLIBCXX_CHECK_LINKER_FEATURES
- GLIBCXX_CHECK_WCHAR_T_SUPPORT
-</pre><p>
- Next come extra compiler/linker feature tests. Wide character
- support was placed here because I couldn't think of another place
- for it. It will probably get broken apart like the math tests,
- because we're still disabling wchars on systems which could actually
- support them.
-</p><pre class="programlisting">
- GLIBCXX_CHECK_SETRLIMIT_ancilliary
- GLIBCXX_CHECK_SETRLIMIT
- GLIBCXX_CHECK_S_ISREG_OR_S_IFREG
- GLIBCXX_CHECK_POLL
- GLIBCXX_CHECK_WRITEV
-
- GLIBCXX_CONFIGURE_TESTSUITE
-</pre><p>
- Feature tests which only get used in one place. Here, things used
- only in the testsuite, plus a couple bits used in the guts of I/O.
-</p><pre class="programlisting">
- GLIBCXX_EXPORT_INCLUDES
- GLIBCXX_EXPORT_FLAGS
- GLIBCXX_EXPORT_INSTALL_INFO
-</pre><p>
- Installation variables, multilibs, working with the rest of the
- compiler. Many of the critical variables used in the makefiles are
- set here.
-</p><pre class="programlisting">
- GLIBGCC_ENABLE
- GLIBCXX_ENABLE_C99
- GLIBCXX_ENABLE_CHEADERS
- GLIBCXX_ENABLE_CLOCALE
- GLIBCXX_ENABLE_CONCEPT_CHECKS
- GLIBCXX_ENABLE_CSTDIO
- GLIBCXX_ENABLE_CXX_FLAGS
- GLIBCXX_ENABLE_C_MBCHAR
- GLIBCXX_ENABLE_DEBUG
- GLIBCXX_ENABLE_DEBUG_FLAGS
- GLIBCXX_ENABLE_LONG_LONG
- GLIBCXX_ENABLE_PCH
- GLIBCXX_ENABLE_SJLJ_EXCEPTIONS
- GLIBCXX_ENABLE_SYMVERS
- GLIBCXX_ENABLE_THREADS
-</pre><p>
- All the features which can be controlled with enable/disable
- configure options. Note how they're alphabetized now? Keep them
- like that. :-)
-</p><pre class="programlisting">
- AC_LC_MESSAGES
- libtool bits
-</pre><p>
- Things which we don't seem to use directly, but just has to be
- present otherwise stuff magically goes wonky.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="build_hacking.enable"></a><code class="constant">GLIBCXX_ENABLE</code>, the <code class="literal">--enable</code> maker</h3></div></div></div><p>
- All the GLIBCXX_ENABLE_FOO macros use a common helper,
- GLIBCXX_ENABLE. (You don't have to use it, but it's easy.) The
- helper does two things for us:
- </p><div class="orderedlist"><ol type="1"><li><p>
- Builds the call to the AC_ARG_ENABLE macro, with --help text
- properly quoted and aligned. (Death to changequote!)
- </p></li><li><p>
- Checks the result against a list of allowed possibilities, and
- signals a fatal error if there's no match. This means that the
- rest of the GLIBCXX_ENABLE_FOO macro doesn't need to test for
- strange arguments, nor do we need to protect against
- empty/whitespace strings with the <code class="code">"x$foo" = "xbar"</code>
- idiom.
- </p></li></ol></div><p>Doing these things correctly takes some extra autoconf/autom4te code,
- which made our macros nearly illegible. So all the ugliness is factored
- out into this one helper macro.
-</p><p>Many of the macros take an argument, passed from when they are expanded
- in configure.ac. The argument controls the default value of the
- enable/disable switch. Previously, the arguments themselves had defaults.
- Now they don't, because that's extra complexity with zero gain for us.
-</p><p>There are three "overloaded signatures". When reading the descriptions
- below, keep in mind that the brackets are autoconf's quotation characters,
- and that they will be stripped. Examples of just about everything occur
- in acinclude.m4, if you want to look.
-</p><pre class="programlisting">
- GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING)
- GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING, permit a|b|c)
- GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING, SHELL-CODE-HANDLER)
-</pre><div class="itemizedlist"><ul type="disc"><li><p>
- FEATURE is the string that follows --enable. The results of the
- test (such as it is) will be in the variable $enable_FEATURE,
- where FEATURE has been squashed. Example:
- <code class="code">[extra-foo]</code>, controlled by the --enable-extra-foo
- option and stored in $enable_extra_foo.
- </p></li><li><p>
- DEFAULT is the value to store in $enable_FEATURE if the user does
- not pass --enable/--disable. It should be one of the permitted
- values passed later. Examples: <code class="code">[yes]</code>, or
- <code class="code">[bar]</code>, or <code class="code">[$1]</code> (which passes the
- argument given to the GLIBCXX_ENABLE_FOO macro as the
- default).
- </p><p>
- For cases where we need to probe for particular models of things,
- it is useful to have an undocumented "auto" value here (see
- GLIBCXX_ENABLE_CLOCALE for an example).
- </p></li><li><p>
- HELP-ARG is any text to append to the option string itself in the
- --help output. Examples: <code class="code">[]</code> (i.e., an empty string,
- which appends nothing), <code class="code">[=BAR]</code>, which produces
- <code class="code">--enable-extra-foo=BAR</code>, and
- <code class="code">[@&lt;:@=BAR@:&gt;@]</code>, which produces
- <code class="code">--enable-extra-foo[=BAR]</code>. See the difference? See
- what it implies to the user?
- </p><p>
- If you're wondering what that line noise in the last example was,
- that's how you embed autoconf special characters in output text.
- They're called <a class="ulink" href="http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_95.html#SEC95" target="_top"><span class="emphasis"><em>quadrigraphs</em></span></a>
- and you should use them whenever necessary.
- </p></li><li><p>HELP-STRING is what you think it is. Do not include the
- "default" text like we used to do; it will be done for you by
- GLIBCXX_ENABLE. By convention, these are not full English
- sentences. Example: [turn on extra foo]
- </p></li></ul></div><p>
- With no other arguments, only the standard autoconf patterns are
- allowed: "<code class="code">--{enable,disable}-foo[={yes,no}]</code>" The
- $enable_FEATURE variable is guaranteed to equal either "yes" or "no"
- after the macro. If the user tries to pass something else, an
- explanatory error message will be given, and configure will halt.
-</p><p>
- The second signature takes a fifth argument, "<code class="code">[permit
- a | b | c | ...]</code>"
- This allows <span class="emphasis"><em>a</em></span> or <span class="emphasis"><em>b</em></span> or
- ... after the equals sign in the option, and $enable_FEATURE is
- guaranteed to equal one of them after the macro. Note that if you
- want to allow plain --enable/--disable with no "=whatever", you must
- include "yes" and "no" in the list of permitted values. Also note
- that whatever you passed as DEFAULT must be in the list. If the
- user tries to pass something not on the list, a semi-explanatory
- error message will be given, and configure will halt. Example:
- <code class="code">[permit generic|gnu|ieee_1003.1-2001|yes|no|auto]</code>
-</p><p>
- The third signature takes a fifth argument. It is arbitrary shell
- code to execute if the user actually passes the enable/disable
- option. (If the user does not, the default is used. Duh.) No
- argument checking at all is done in this signature. See
- GLIBCXX_ENABLE_CXX_FLAGS for an example of handling, and an error
- message.
-</p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="source_design_notes.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="internals.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Design Notes </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Porting to New Hardware or Operating Systems</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/associative.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/associative.html
deleted file mode 100644
index 54102abf8..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/associative.html
+++ /dev/null
@@ -1,87 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 17. Associative</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="containers.html" title="Part VII.  Containers" /><link rel="prev" href="vector.html" title="vector" /><link rel="next" href="bitset.html" title="bitset" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 17. Associative</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="vector.html">Prev</a> </td><th width="60%" align="center">Part VII. 
- Containers
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bitset.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.containers.associative"></a>Chapter 17. Associative</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="associative.html#containers.associative.insert_hints">Insertion Hints</a></span></dt><dt><span class="sect1"><a href="bitset.html">bitset</a></span></dt><dd><dl><dt><span class="sect2"><a href="bitset.html#associative.bitset.size_variable">Size Variable</a></span></dt><dt><span class="sect2"><a href="bitset.html#associative.bitset.type_string">Type String</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="containers.associative.insert_hints"></a>Insertion Hints</h2></div></div></div><p>
- Section [23.1.2], Table 69, of the C++ standard lists this
- function for all of the associative containers (map, set, etc):
- </p><pre class="programlisting">
- a.insert(p,t);
- </pre><p>
- where 'p' is an iterator into the container 'a', and 't' is the
- item to insert. The standard says that “<span class="quote"><code class="code">t</code> is
- inserted as close as possible to the position just prior to
- <code class="code">p</code>.</span>” (Library DR #233 addresses this topic,
- referring to <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html" target="_top">N1780</a>.
- Since version 4.2 GCC implements the resolution to DR 233, so
- that insertions happen as close as possible to the hint. For
- earlier releases the hint was only used as described below.
- </p><p>
- Here we'll describe how the hinting works in the libstdc++
- implementation, and what you need to do in order to take
- advantage of it. (Insertions can change from logarithmic
- complexity to amortized constant time, if the hint is properly
- used.) Also, since the current implementation is based on the
- SGI STL one, these points may hold true for other library
- implementations also, since the HP/SGI code is used in a lot of
- places.
- </p><p>
- In the following text, the phrases <span class="emphasis"><em>greater
- than</em></span> and <span class="emphasis"><em>less than</em></span> refer to the
- results of the strict weak ordering imposed on the container by
- its comparison object, which defaults to (basically)
- “<span class="quote">&lt;</span>”. Using those phrases is semantically sloppy,
- but I didn't want to get bogged down in syntax. I assume that if
- you are intelligent enough to use your own comparison objects,
- you are also intelligent enough to assign “<span class="quote">greater</span>”
- and “<span class="quote">lesser</span>” their new meanings in the next
- paragraph. *grin*
- </p><p>
- If the <code class="code">hint</code> parameter ('p' above) is equivalent to:
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- <code class="code">begin()</code>, then the item being inserted should
- have a key less than all the other keys in the container.
- The item will be inserted at the beginning of the container,
- becoming the new entry at <code class="code">begin()</code>.
- </p></li><li><p>
- <code class="code">end()</code>, then the item being inserted should have
- a key greater than all the other keys in the container. The
- item will be inserted at the end of the container, becoming
- the new entry at <code class="code">end()</code>.
- </p></li><li><p>
- neither <code class="code">begin()</code> nor <code class="code">end()</code>, then:
- Let <code class="code">h</code> be the entry in the container pointed to
- by <code class="code">hint</code>, that is, <code class="code">h = *hint</code>. Then
- the item being inserted should have a key less than that of
- <code class="code">h</code>, and greater than that of the item preceding
- <code class="code">h</code>. The new item will be inserted between
- <code class="code">h</code> and <code class="code">h</code>'s predecessor.
- </p></li></ul></div><p>
- For <code class="code">multimap</code> and <code class="code">multiset</code>, the
- restrictions are slightly looser: “<span class="quote">greater than</span>”
- should be replaced by “<span class="quote">not less than</span>”and “<span class="quote">less
- than</span>” should be replaced by “<span class="quote">not greater
- than.</span>” (Why not replace greater with
- greater-than-or-equal-to? You probably could in your head, but
- the mathematicians will tell you that it isn't the same thing.)
- </p><p>
- If the conditions are not met, then the hint is not used, and the
- insertion proceeds as if you had called <code class="code"> a.insert(t)
- </code> instead. (<span class="emphasis"><em>Note </em></span> that GCC releases
- prior to 3.0.2 had a bug in the case with <code class="code">hint ==
- begin()</code> for the <code class="code">map</code> and <code class="code">set</code>
- classes. You should not use a hint argument in those releases.)
- </p><p>
- This behavior goes well with other containers'
- <code class="code">insert()</code> functions which take an iterator: if used,
- the new item will be inserted before the iterator passed as an
- argument, same as the other containers.
- </p><p>
- <span class="emphasis"><em>Note </em></span> also that the hint in this
- implementation is a one-shot. The older insertion-with-hint
- routines check the immediately surrounding entries to ensure that
- the new item would in fact belong there. If the hint does not
- point to the correct place, then no further local searching is
- done; the search begins from scratch in logarithmic time.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="vector.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="containers.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bitset.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">vector </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> bitset</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/auto_ptr.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/auto_ptr.html
deleted file mode 100644
index 9da480093..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/auto_ptr.html
+++ /dev/null
@@ -1,90 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>auto_ptr</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; auto_ptr&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="memory.html" title="Chapter 11. Memory" /><link rel="prev" href="memory.html" title="Chapter 11. Memory" /><link rel="next" href="shared_ptr.html" title="shared_ptr" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">auto_ptr</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="memory.html">Prev</a> </td><th width="60%" align="center">Chapter 11. Memory</th><td width="20%" align="right"> <a accesskey="n" href="shared_ptr.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.util.memory.auto_ptr"></a>auto_ptr</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="auto_ptr.limitations"></a>Limitations</h3></div></div></div><p>Explaining all of the fun and delicious things that can
- happen with misuse of the <code class="classname">auto_ptr</code> class
- template (called <acronym class="acronym">AP</acronym> here) would take some
- time. Suffice it to say that the use of <acronym class="acronym">AP</acronym>
- safely in the presence of copying has some subtleties.
- </p><p>
- The AP class is a really
- nifty idea for a smart pointer, but it is one of the dumbest of
- all the smart pointers -- and that's fine.
- </p><p>
- AP is not meant to be a supersmart solution to all resource
- leaks everywhere. Neither is it meant to be an effective form
- of garbage collection (although it can help, a little bit).
- And it can <span class="emphasis"><em>not</em></span>be used for arrays!
- </p><p>
- <acronym class="acronym">AP</acronym> is meant to prevent nasty leaks in the
- presence of exceptions. That's <span class="emphasis"><em>all</em></span>. This
- code is AP-friendly:
- </p><pre class="programlisting">
- // Not a recommend naming scheme, but good for web-based FAQs.
- typedef std::auto_ptr&lt;MyClass&gt; APMC;
-
- extern function_taking_MyClass_pointer (MyClass*);
- extern some_throwable_function ();
-
- void func (int data)
- {
- APMC ap (new MyClass(data));
-
- some_throwable_function(); // this will throw an exception
-
- function_taking_MyClass_pointer (ap.get());
- }
- </pre><p>When an exception gets thrown, the instance of MyClass that's
- been created on the heap will be <code class="function">delete</code>'d as the stack is
- unwound past <code class="function">func()</code>.
- </p><p>Changing that code as follows is not <acronym class="acronym">AP</acronym>-friendly:
- </p><pre class="programlisting">
- APMC ap (new MyClass[22]);
- </pre><p>You will get the same problems as you would without the use
- of <acronym class="acronym">AP</acronym>:
- </p><pre class="programlisting">
- char* array = new char[10]; // array new...
- ...
- delete array; // ...but single-object delete
- </pre><p>
- AP cannot tell whether the pointer you've passed at creation points
- to one or many things. If it points to many things, you are about
- to die. AP is trivial to write, however, so you could write your
- own <code class="code">auto_array_ptr</code> for that situation (in fact, this has
- been done many times; check the mailing lists, Usenet, Boost, etc).
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="auto_ptr.using"></a>Use in Containers</h3></div></div></div><p>
- </p><p>All of the <a class="ulink" href="../23_containers/howto.html" target="_top">containers</a>
- described in the standard library require their contained types
- to have, among other things, a copy constructor like this:
- </p><pre class="programlisting">
- struct My_Type
- {
- My_Type (My_Type const&amp;);
- };
- </pre><p>
- Note the const keyword; the object being copied shouldn't change.
- The template class <code class="code">auto_ptr</code> (called AP here) does not
- meet this requirement. Creating a new AP by copying an existing
- one transfers ownership of the pointed-to object, which means that
- the AP being copied must change, which in turn means that the
- copy ctors of AP do not take const objects.
- </p><p>
- The resulting rule is simple: <span class="emphasis"><em>Never ever use a
- container of auto_ptr objects</em></span>. The standard says that
- “<span class="quote">undefined</span>” behavior is the result, but it is
- guaranteed to be messy.
- </p><p>
- To prevent you from doing this to yourself, the
- <a class="ulink" href="../19_diagnostics/howto.html#3" target="_top">concept checks</a> built
- in to this implementation will issue an error if you try to
- compile code like this:
- </p><pre class="programlisting">
- #include &lt;vector&gt;
- #include &lt;memory&gt;
-
- void f()
- {
- std::vector&lt; std::auto_ptr&lt;int&gt; &gt; vec_ap_int;
- }
- </pre><p>
-Should you try this with the checks enabled, you will see an error.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="memory.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="memory.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="shared_ptr.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 11. Memory </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> shared_ptr</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/backwards.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/backwards.html
deleted file mode 100644
index fc28c51e1..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/backwards.html
+++ /dev/null
@@ -1,932 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Backwards Compatibility</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; backwards&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_porting.html" title="Appendix B.  Porting and Maintenance" /><link rel="prev" href="api.html" title="API Evolution and Deprecation History" /><link rel="next" href="appendix_free.html" title="Appendix C.  Free Software Needs Free Documentation" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Backwards Compatibility</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="api.html">Prev</a> </td><th width="60%" align="center">Appendix B. 
- Porting and Maintenance
-
-</th><td width="20%" align="right"> <a accesskey="n" href="appendix_free.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.appendix.porting.backwards"></a>Backwards Compatibility</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.first"></a>First</h3></div></div></div><p>The first generation GNU C++ library was called libg++. It was a
-separate GNU project, although reliably paired with GCC. Rumors imply
-that it had a working relationship with at least two kinds of
-dinosaur.
-</p><p>Some background: libg++ was designed and created when there was no
-ISO standard to provide guidance. Classes like linked lists are now
-provided for by <code class="classname">list&lt;T&gt;</code> and do not need to be
-created by <code class="function">genclass</code>. (For that matter, templates exist
-now and are well-supported, whereas genclass (mostly) predates them.)
-</p><p>There are other classes in libg++ that are not specified in the
-ISO Standard (e.g., statistical analysis). While there are a lot of
-really useful things that are used by a lot of people, the Standards
-Committee couldn't include everything, and so a lot of those
-“<span class="quote">obvious</span>” classes didn't get included.
-</p><p>Known Issues include many of the limitations of its immediate ancestor.</p><p>Portability notes and known implementation limitations are as follows.</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id459608"></a>No <code class="code">ios_base</code></h4></div></div></div><p> At least some older implementations don't have <code class="code">std::ios_base</code>, so you should use <code class="code">std::ios::badbit</code>, <code class="code">std::ios::failbit</code> and <code class="code">std::ios::eofbit</code> and <code class="code">std::ios::goodbit</code>.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id444641"></a>No <code class="code">cout</code> in <code class="code">ostream.h</code>, no <code class="code">cin</code> in <code class="code">istream.h</code></h4></div></div></div><p>
- In earlier versions of the standard,
- <code class="filename">fstream.h</code>,
- <code class="filename">ostream.h</code>
- and <code class="filename">istream.h</code>
- used to define
- <code class="code">cout</code>, <code class="code">cin</code> and so on. ISO C++ specifies that one needs to include
- <code class="filename">iostream</code>
- explicitly to get the required definitions.
- </p><p> Some include adjustment may be required.</p><p>This project is no longer maintained or supported, and the sources
-archived. For the desperate,
-the <a class="ulink" href="http://gcc.gnu.org/extensions.html" target="_top">GCC extensions
-page</a> describes where to find the last libg++ source. The code is
-considered replaced and rewritten.
-</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.second"></a>Second</h3></div></div></div><p>
- The second generation GNU C++ library was called libstdc++, or
- libstdc++-v2. It spans the time between libg++ and pre-ISO C++
- standardization and is usually associated with the following GCC
- releases: egcs 1.x, gcc 2.95, and gcc 2.96.
-</p><p>
- The STL portions of this library are based on SGI/HP STL release 3.11.
-</p><p>
- This project is no longer maintained or supported, and the sources
- archived. The code is considered replaced and rewritten.
-</p><p>
- Portability notes and known implementation limitations are as follows.
-</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id444741"></a>Namespace <code class="code">std::</code> not supported</h4></div></div></div><p>
- Some care is required to support C++ compiler and or library
- implementation that do not have the standard library in
- <code class="code">namespace std</code>.
- </p><p>
- The following sections list some possible solutions to support compilers
- that cannot ignore <code class="code">std::</code>-qualified names.
- </p><p>
- First, see if the compiler has a flag for this. Namespace
- back-portability-issues are generally not a problem for g++
- compilers that do not have libstdc++ in <code class="code">std::</code>, as the
- compilers use <code class="code">-fno-honor-std</code> (ignore
- <code class="code">std::</code>, <code class="code">:: = std::</code>) by default. That is,
- the responsibility for enabling or disabling <code class="code">std::</code> is
- on the user; the maintainer does not have to care about it. This
- probably applies to some other compilers as well.
- </p><p>
- Second, experiment with a variety of pre-processor tricks.
- </p><p>
- By defining <code class="code">std</code> as a macro, fully-qualified namespace
- calls become global. Volia.
- </p><pre class="programlisting">
-#ifdef WICKEDLY_OLD_COMPILER
-# define std
-#endif
-</pre><p>
- Thanks to Juergen Heinzl who posted this solution on gnu.gcc.help.
- </p><p>
- Another pre-processor based approach is to define a macro
- <code class="code">NAMESPACE_STD</code>, which is defined to either
- “<span class="quote"> </span>” or “<span class="quote">std</span>” based on a compile-type
- test. On GNU systems, this can be done with autotools by means of
- an autoconf test (see below) for <code class="code">HAVE_NAMESPACE_STD</code>,
- then using that to set a value for the <code class="code">NAMESPACE_STD</code>
- macro. At that point, one is able to use
- <code class="code">NAMESPACE_STD::string</code>, which will evaluate to
- <code class="code">std::string</code> or <code class="code">::string</code> (i.e., in the
- global namespace on systems that do not put <code class="code">string</code> in
- <code class="code">std::</code>).
- </p><pre class="programlisting">
-dnl @synopsis AC_CXX_NAMESPACE_STD
-dnl
-dnl If the compiler supports namespace std, define
-dnl HAVE_NAMESPACE_STD.
-dnl
-dnl @category Cxx
-dnl @author Todd Veldhuizen
-dnl @author Luc Maisonobe &lt;luc@spaceroots.org&gt;
-dnl @version 2004-02-04
-dnl @license AllPermissive
-AC_DEFUN([AC_CXX_NAMESPACE_STD], [
- AC_CACHE_CHECK(if g++ supports namespace std,
- ac_cv_cxx_have_std_namespace,
- [AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- AC_TRY_COMPILE([#include &lt;iostream&gt;
- std::istream&amp; is = std::cin;],,
- ac_cv_cxx_have_std_namespace=yes, ac_cv_cxx_have_std_namespace=no)
- AC_LANG_RESTORE
- ])
- if test "$ac_cv_cxx_have_std_namespace" = yes; then
- AC_DEFINE(HAVE_NAMESPACE_STD,,[Define if g++ supports namespace std. ])
- fi
-])
-</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id444864"></a>Illegal iterator usage</h4></div></div></div><p>
- The following illustrate implementation-allowed illegal iterator
- use, and then correct use.
-</p><div class="itemizedlist"><ul type="disc"><li><p>
- you cannot do <code class="code">ostream::operator&lt;&lt;(iterator)</code>
- to print the address of the iterator =&gt; use
- <code class="code">operator&lt;&lt; &amp;*iterator</code> instead
- </p></li><li><p>
- you cannot clear an iterator's reference (<code class="code">iterator =
- 0</code>) =&gt; use <code class="code">iterator = iterator_type();</code>
- </p></li><li><p>
- <code class="code">if (iterator)</code> won't work any more =&gt; use
- <code class="code">if (iterator != iterator_type())</code>
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id444925"></a><code class="code">isspace</code> from <code class="filename">cctype</code> is a macro
- </h4></div></div></div><p>
- Glibc 2.0.x and 2.1.x define <code class="filename">ctype.h</code> functionality as macros
- (isspace, isalpha etc.).
- </p><p>
- This implementations of libstdc++, however, keep these functions
- as macros, and so it is not back-portable to use fully qualified
- names. For example:
- </p><pre class="programlisting">
-#include &lt;cctype&gt;
-int main() { std::isspace('X'); }
-</pre><p>
- Results in something like this:
-</p><pre class="programlisting">
-std:: (__ctype_b[(int) ( ( 'X' ) )] &amp; (unsigned short int) _ISspace ) ;
-</pre><p>
- A solution is to modify a header-file so that the compiler tells
- <code class="filename">ctype.h</code> to define functions
- instead of macros:
-</p><pre class="programlisting">
-// This keeps isalnum, et al from being propagated as macros.
-#if __linux__
-# define __NO_CTYPE 1
-#endif
-</pre><p>
- Then, include <code class="filename">ctype.h</code>
-</p><p>
- Another problem arises if you put a <code class="code">using namespace
- std;</code> declaration at the top, and include <code class="filename">ctype.h</code>. This will result in
- ambiguities between the definitions in the global namespace
- (<code class="filename">ctype.h</code>) and the
- definitions in namespace <code class="code">std::</code>
- (<code class="code">&lt;cctype&gt;</code>).
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id445019"></a>No <code class="code">vector::at</code>, <code class="code">deque::at</code>, <code class="code">string::at</code></h4></div></div></div><p>
- One solution is to add an autoconf-test for this:
-</p><pre class="programlisting">
-AC_MSG_CHECKING(for container::at)
-AC_TRY_COMPILE(
-[
-#include &lt;vector&gt;
-#include &lt;deque&gt;
-#include &lt;string&gt;
-
-using namespace std;
-],
-[
-deque&lt;int&gt; test_deque(3);
-test_deque.at(2);
-vector&lt;int&gt; test_vector(2);
-test_vector.at(1);
-string test_string(“<span class="quote">test_string</span>”);
-test_string.at(3);
-],
-[AC_MSG_RESULT(yes)
-AC_DEFINE(HAVE_CONTAINER_AT)],
-[AC_MSG_RESULT(no)])
-</pre><p>
- If you are using other (non-GNU) compilers it might be a good idea
- to check for <code class="code">string::at</code> separately.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id445057"></a>No <code class="code">std::char_traits&lt;char&gt;::eof</code></h4></div></div></div><p>
- Use some kind of autoconf test, plus this:
-</p><pre class="programlisting">
-#ifdef HAVE_CHAR_TRAITS
-#define CPP_EOF std::char_traits&lt;char&gt;::eof()
-#else
-#define CPP_EOF EOF
-#endif
-</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id445075"></a>No <code class="code">string::clear</code></h4></div></div></div><p>
- There are two functions for deleting the contents of a string:
- <code class="code">clear</code> and <code class="code">erase</code> (the latter returns the
- string).
-</p><pre class="programlisting">
-void
-clear() { _M_mutate(0, this-&gt;size(), 0); }
-</pre><pre class="programlisting">
-basic_string&amp;
-erase(size_type __pos = 0, size_type __n = npos)
-{
- return this-&gt;replace(_M_check(__pos), _M_fold(__pos, __n),
- _M_data(), _M_data());
-}
-</pre><p>
- Unfortunately, <code class="code">clear</code> is not implemented in this
- version, so you should use <code class="code">erase</code> (which is probably
- faster than <code class="code">operator=(charT*)</code>).
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id445120"></a>
- Removal of <code class="code">ostream::form</code> and <code class="code">istream::scan</code>
- extensions
-</h4></div></div></div><p>
- These are no longer supported. Please use stringstreams instead.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id445139"></a>No <code class="code">basic_stringbuf</code>, <code class="code">basic_stringstream</code></h4></div></div></div><p>
- Although the ISO standard <code class="code">i/ostringstream</code>-classes are
- provided, (<code class="filename">sstream</code>), for
- compatibility with older implementations the pre-ISO
- <code class="code">i/ostrstream</code> (<code class="filename">strstream</code>) interface is also provided,
- with these caveats:
-</p><div class="itemizedlist"><ul type="disc"><li><p>
- <code class="code">strstream</code> is considered to be deprecated
- </p></li><li><p>
- <code class="code">strstream</code> is limited to <code class="code">char</code>
- </p></li><li><p>
- with <code class="code">ostringstream</code> you don't have to take care of
- terminating the string or freeing its memory
- </p></li><li><p>
- <code class="code">istringstream</code> can be re-filled (clear();
- str(input);)
- </p></li></ul></div><p>
- You can then use output-stringstreams like this:
-</p><pre class="programlisting">
-#ifdef HAVE_SSTREAM
-# include &lt;sstream&gt;
-#else
-# include &lt;strstream&gt;
-#endif
-
-#ifdef HAVE_SSTREAM
- std::ostringstream oss;
-#else
- std::ostrstream oss;
-#endif
-
-oss &lt;&lt; “<span class="quote">Name=</span>” &lt;&lt; m_name &lt;&lt; “<span class="quote">, number=</span>” &lt;&lt; m_number &lt;&lt; std::endl;
-...
-#ifndef HAVE_SSTREAM
- oss &lt;&lt; std::ends; // terminate the char*-string
-#endif
-
-// str() returns char* for ostrstream and a string for ostringstream
-// this also causes ostrstream to think that the buffer's memory
-// is yours
-m_label.set_text(oss.str());
-#ifndef HAVE_SSTREAM
- // let the ostrstream take care of freeing the memory
- oss.freeze(false);
-#endif
-</pre><p>
- Input-stringstreams can be used similarly:
-</p><pre class="programlisting">
-std::string input;
-...
-#ifdef HAVE_SSTREAM
-std::istringstream iss(input);
-#else
-std::istrstream iss(input.c_str());
-#endif
-
-int i;
-iss &gt;&gt; i;
-</pre><p> One (the only?) restriction is that an istrstream cannot be re-filled:
-</p><pre class="programlisting">
-std::istringstream iss(numerator);
-iss &gt;&gt; m_num;
-// this is not possible with istrstream
-iss.clear();
-iss.str(denominator);
-iss &gt;&gt; m_den;
-</pre><p>
-If you don't care about speed, you can put these conversions in
- a template-function:
-</p><pre class="programlisting">
-template &lt;class X&gt;
-void fromString(const string&amp; input, X&amp; any)
-{
-#ifdef HAVE_SSTREAM
-std::istringstream iss(input);
-#else
-std::istrstream iss(input.c_str());
-#endif
-X temp;
-iss &gt;&gt; temp;
-if (iss.fail())
-throw runtime_error(..)
-any = temp;
-}
-</pre><p>
- Another example of using stringstreams is in <a class="link" href="bk01pt05ch13s05.html" title="Shrink to Fit">this howto</a>.
-</p><p> There is additional information in the libstdc++-v2 info files, in
-particular “<span class="quote">info iostream</span>”.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id448793"></a>Little or no wide character support</h4></div></div></div><p>
- Classes <code class="classname">wstring</code> and
- <code class="classname">char_traits&lt;wchar_t&gt;</code> are
- not supported.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id448812"></a>No templatized iostreams</h4></div></div></div><p>
- Classes <code class="classname">wfilebuf</code> and
- <code class="classname">wstringstream</code> are not supported.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id448831"></a>Thread safety issues</h4></div></div></div><p>
- Earlier GCC releases had a somewhat different approach to
- threading configuration and proper compilation. Before GCC 3.0,
- configuration of the threading model was dictated by compiler
- command-line options and macros (both of which were somewhat
- thread-implementation and port-specific). There were no
- guarantees related to being able to link code compiled with one
- set of options and macro setting with another set.
- </p><p>
- For GCC 3.0, configuration of the threading model used with
- libraries and user-code is performed when GCC is configured and
- built using the --enable-threads and --disable-threads options.
- The ABI is stable for symbol name-mangling and limited functional
- compatibility exists between code compiled under different
- threading models.
- </p><p>
- The libstdc++ library has been designed so that it can be used in
- multithreaded applications (with libstdc++-v2 this was only true
- of the STL parts.) The first problem is finding a
- <span class="emphasis"><em>fast</em></span> method of implementation portable to
- all platforms. Due to historical reasons, some of the library is
- written against per-CPU-architecture spinlocks and other parts
- against the gthr.h abstraction layer which is provided by gcc. A
- minor problem that pops up every so often is different
- interpretations of what "thread-safe" means for a
- library (not a general program). We currently use the <a class="ulink" href="http://www.sgi.com/tech/stl/thread_safety.html" target="_top">same
- definition that SGI</a> uses for their STL subset. However,
- the exception for read-only containers only applies to the STL
- components. This definition is widely-used and something similar
- will be used in the next version of the C++ standard library.
- </p><p>
- Here is a small link farm to threads (no pun) in the mail
- archives that discuss the threading problem. Each link is to the
- first relevant message in the thread; from there you can use
- "Thread Next" to move down the thread. This farm is in
- latest-to-oldest order.
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- Our threading expert Loren gives a breakdown of <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2001-10/msg00024.html" target="_top">the
- six situations involving threads</a> for the 3.0
- release series.
- </p></li><li><p>
- <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html" target="_top">
- This message</a> inspired a recent updating of issues with
- threading and the SGI STL library. It also contains some
- example POSIX-multithreaded STL code.
- </p></li></ul></div><p>
- (A large selection of links to older messages has been removed;
- many of the messages from 1999 were lost in a disk crash, and the
- few people with access to the backup tapes have been too swamped
- with work to restore them. Many of the points have been
- superseded anyhow.)
- </p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.third"></a>Third</h3></div></div></div><p> The third generation GNU C++ library is called libstdc++, or
-libstdc++-v3.
-</p><p>The subset commonly known as the Standard Template Library
- (chapters 23 through 25, mostly) is adapted from the final release
- of the SGI STL (version 3.3), with extensive changes.
- </p><p>A more formal description of the V3 goals can be found in the
- official <a class="ulink" href="../17_intro/DESIGN" target="_top">design document</a>.
- </p><p>Portability notes and known implementation limitations are as follows.</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id448950"></a>Pre-ISO headers moved to backwards or removed</h4></div></div></div><p> The pre-ISO C++ headers
- (<code class="code">iostream.h</code>, <code class="code">defalloc.h</code> etc.) are
- available, unlike previous libstdc++ versions, but inclusion
- generates a warning that you are using deprecated headers.
-</p><p>This compatibility layer is constructed by including the
- standard C++ headers, and injecting any items in
- <code class="code">std::</code> into the global namespace.
- </p><p>For those of you new to ISO C++ (welcome, time travelers!), no,
- that isn't a typo. Yes, the headers really have new names.
- Marshall Cline's C++ FAQ Lite has a good explanation in <a class="ulink" href="http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.4" target="_top">item
- [27.4]</a>.
- </p><p> Some include adjustment may be required. What follows is an
-autoconf test that defines <code class="code">PRE_STDCXX_HEADERS</code> when they
-exist.</p><pre class="programlisting">
-# AC_HEADER_PRE_STDCXX
-AC_DEFUN([AC_HEADER_PRE_STDCXX], [
- AC_CACHE_CHECK(for pre-ISO C++ include files,
- ac_cv_cxx_pre_stdcxx,
- [AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -Wno-deprecated"
-
- # Omit defalloc.h, as compilation with newer compilers is problematic.
- AC_TRY_COMPILE([
- #include &lt;new.h&gt;
- #include &lt;iterator.h&gt;
- #include &lt;alloc.h&gt;
- #include &lt;set.h&gt;
- #include &lt;hashtable.h&gt;
- #include &lt;hash_set.h&gt;
- #include &lt;fstream.h&gt;
- #include &lt;tempbuf.h&gt;
- #include &lt;istream.h&gt;
- #include &lt;bvector.h&gt;
- #include &lt;stack.h&gt;
- #include &lt;rope.h&gt;
- #include &lt;complex.h&gt;
- #include &lt;ostream.h&gt;
- #include &lt;heap.h&gt;
- #include &lt;iostream.h&gt;
- #include &lt;function.h&gt;
- #include &lt;multimap.h&gt;
- #include &lt;pair.h&gt;
- #include &lt;stream.h&gt;
- #include &lt;iomanip.h&gt;
- #include &lt;slist.h&gt;
- #include &lt;tree.h&gt;
- #include &lt;vector.h&gt;
- #include &lt;deque.h&gt;
- #include &lt;multiset.h&gt;
- #include &lt;list.h&gt;
- #include &lt;map.h&gt;
- #include &lt;algobase.h&gt;
- #include &lt;hash_map.h&gt;
- #include &lt;algo.h&gt;
- #include &lt;queue.h&gt;
- #include &lt;streambuf.h&gt;
- ],,
- ac_cv_cxx_pre_stdcxx=yes, ac_cv_cxx_pre_stdcxx=no)
- CXXFLAGS="$ac_save_CXXFLAGS"
- AC_LANG_RESTORE
- ])
- if test "$ac_cv_cxx_pre_stdcxx" = yes; then
- AC_DEFINE(PRE_STDCXX_HEADERS,,[Define if pre-ISO C++ header files are present. ])
- fi
-])
-</pre><p>Porting between pre-ISO headers and ISO headers is simple: headers
-like <code class="filename">vector.h</code> can be replaced with <code class="filename">vector</code> and a using
-directive <code class="code">using namespace std;</code> can be put at the global
-scope. This should be enough to get this code compiling, assuming the
-other usage is correct.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id449032"></a>Extension headers hash_map, hash_set moved to ext or backwards</h4></div></div></div><p>At this time most of the features of the SGI STL extension have been
- replaced by standardized libraries.
- In particular, the unordered_map and unordered_set containers of TR1
- are suitable replacement for the non-standard hash_map and hash_set
- containers in the SGI STL.
- </p><p> Header files <code class="filename">hash_map</code> and <code class="filename">hash_set</code> moved
-to <code class="filename">ext/hash_map</code> and <code class="filename">ext/hash_set</code>,
-respectively. At the same time, all types in these files are enclosed
-in <code class="code">namespace __gnu_cxx</code>. Later versions move deprecate
-these files, and suggest using TR1's <code class="filename">unordered_map</code>
-and <code class="filename">unordered_set</code> instead.
-</p><p>The extensions are no longer in the global or <code class="code">std</code>
- namespaces, instead they are declared in the <code class="code">__gnu_cxx</code>
- namespace. For maximum portability, consider defining a namespace
- alias to use to talk about extensions, e.g.:
- </p><pre class="programlisting">
- #ifdef __GNUC__
- #if __GNUC__ &lt; 3
- #include &lt;hash_map.h&gt;
- namespace extension { using ::hash_map; }; // inherit globals
- #else
- #include &lt;backward/hash_map&gt;
- #if __GNUC__ == 3 &amp;&amp; __GNUC_MINOR__ == 0
- namespace extension = std; // GCC 3.0
- #else
- namespace extension = ::__gnu_cxx; // GCC 3.1 and later
- #endif
- #endif
- #else // ... there are other compilers, right?
- namespace extension = std;
- #endif
-
- extension::hash_map&lt;int,int&gt; my_map;
- </pre><p>This is a bit cleaner than defining typedefs for all the
- instantiations you might need.
- </p><p>The following autoconf tests check for working HP/SGI hash containers.
-</p><pre class="programlisting">
-# AC_HEADER_EXT_HASH_MAP
-AC_DEFUN([AC_HEADER_EXT_HASH_MAP], [
- AC_CACHE_CHECK(for ext/hash_map,
- ac_cv_cxx_ext_hash_map,
- [AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -Werror"
- AC_TRY_COMPILE([#include &lt;ext/hash_map&gt;], [using __gnu_cxx::hash_map;],
- ac_cv_cxx_ext_hash_map=yes, ac_cv_cxx_ext_hash_map=no)
- CXXFLAGS="$ac_save_CXXFLAGS"
- AC_LANG_RESTORE
- ])
- if test "$ac_cv_cxx_ext_hash_map" = yes; then
- AC_DEFINE(HAVE_EXT_HASH_MAP,,[Define if ext/hash_map is present. ])
- fi
-])
-</pre><pre class="programlisting">
-# AC_HEADER_EXT_HASH_SET
-AC_DEFUN([AC_HEADER_EXT_HASH_SET], [
- AC_CACHE_CHECK(for ext/hash_set,
- ac_cv_cxx_ext_hash_set,
- [AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -Werror"
- AC_TRY_COMPILE([#include &lt;ext/hash_set&gt;], [using __gnu_cxx::hash_set;],
- ac_cv_cxx_ext_hash_set=yes, ac_cv_cxx_ext_hash_set=no)
- CXXFLAGS="$ac_save_CXXFLAGS"
- AC_LANG_RESTORE
- ])
- if test "$ac_cv_cxx_ext_hash_set" = yes; then
- AC_DEFINE(HAVE_EXT_HASH_SET,,[Define if ext/hash_set is present. ])
- fi
-])
-</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id449135"></a>No <code class="code">ios::nocreate/ios::noreplace</code>.
-</h4></div></div></div><p> The existence of <code class="code">ios::nocreate</code> being used for
-input-streams has been confirmed, most probably because the author
-thought it would be more correct to specify nocreate explicitly. So
-it can be left out for input-streams.
-</p><p>For output streams, “<span class="quote">nocreate</span>” is probably the default,
-unless you specify <code class="code">std::ios::trunc</code> ? To be safe, you can
-open the file for reading, check if it has been opened, and then
-decide whether you want to create/replace or not. To my knowledge,
-even older implementations support <code class="code">app</code>, <code class="code">ate</code>
-and <code class="code">trunc</code> (except for <code class="code">app</code> ?).
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id449183"></a>
-No <code class="code">stream::attach(int fd)</code>
-</h4></div></div></div><p>
- Phil Edwards writes: It was considered and rejected for the ISO
- standard. Not all environments use file descriptors. Of those
- that do, not all of them use integers to represent them.
- </p><p>
- For a portable solution (among systems which use
- file descriptors), you need to implement a subclass of
- <code class="code">std::streambuf</code> (or
- <code class="code">std::basic_streambuf&lt;..&gt;</code>) which opens a file
- given a descriptor, and then pass an instance of this to the
- stream-constructor.
- </p><p>
- An extension is available that implements this.
- <code class="filename">ext/stdio_filebuf.h</code> contains a derived class called
- <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/class____gnu__cxx_1_1stdio__filebuf.html" target="_top"><code class="code">__gnu_cxx::stdio_filebuf</code></a>.
- This class can be constructed from a C <code class="code">FILE*</code> or a file
- descriptor, and provides the <code class="code">fd()</code> function.
- </p><p>
- For another example of this, refer to
- <a class="ulink" href="http://www.josuttis.com/cppcode/fdstream.html" target="_top">fdstream example</a>
- by Nicolai Josuttis.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id511531"></a>
-Support for C++98 dialect.
-</h4></div></div></div><p>Check for complete library coverage of the C++1998/2003 standard.
-</p><pre class="programlisting">
-# AC_HEADER_STDCXX_98
-AC_DEFUN([AC_HEADER_STDCXX_98], [
- AC_CACHE_CHECK(for ISO C++ 98 include files,
- ac_cv_cxx_stdcxx_98,
- [AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- AC_TRY_COMPILE([
- #include &lt;cassert&gt;
- #include &lt;cctype&gt;
- #include &lt;cerrno&gt;
- #include &lt;cfloat&gt;
- #include &lt;ciso646&gt;
- #include &lt;climits&gt;
- #include &lt;clocale&gt;
- #include &lt;cmath&gt;
- #include &lt;csetjmp&gt;
- #include &lt;csignal&gt;
- #include &lt;cstdarg&gt;
- #include &lt;cstddef&gt;
- #include &lt;cstdio&gt;
- #include &lt;cstdlib&gt;
- #include &lt;cstring&gt;
- #include &lt;ctime&gt;
-
- #include &lt;algorithm&gt;
- #include &lt;bitset&gt;
- #include &lt;complex&gt;
- #include &lt;deque&gt;
- #include &lt;exception&gt;
- #include &lt;fstream&gt;
- #include &lt;functional&gt;
- #include &lt;iomanip&gt;
- #include &lt;ios&gt;
- #include &lt;iosfwd&gt;
- #include &lt;iostream&gt;
- #include &lt;istream&gt;
- #include &lt;iterator&gt;
- #include &lt;limits&gt;
- #include &lt;list&gt;
- #include &lt;locale&gt;
- #include &lt;map&gt;
- #include &lt;memory&gt;
- #include &lt;new&gt;
- #include &lt;numeric&gt;
- #include &lt;ostream&gt;
- #include &lt;queue&gt;
- #include &lt;set&gt;
- #include &lt;sstream&gt;
- #include &lt;stack&gt;
- #include &lt;stdexcept&gt;
- #include &lt;streambuf&gt;
- #include &lt;string&gt;
- #include &lt;typeinfo&gt;
- #include &lt;utility&gt;
- #include &lt;valarray&gt;
- #include &lt;vector&gt;
- ],,
- ac_cv_cxx_stdcxx_98=yes, ac_cv_cxx_stdcxx_98=no)
- AC_LANG_RESTORE
- ])
- if test "$ac_cv_cxx_stdcxx_98" = yes; then
- AC_DEFINE(STDCXX_98_HEADERS,,[Define if ISO C++ 1998 header files are present. ])
- fi
-])
-</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id511558"></a>
-Support for C++TR1 dialect.
-</h4></div></div></div><p>Check for library coverage of the TR1 standard.
-</p><pre class="programlisting">
-# AC_HEADER_STDCXX_TR1
-AC_DEFUN([AC_HEADER_STDCXX_TR1], [
- AC_CACHE_CHECK(for ISO C++ TR1 include files,
- ac_cv_cxx_stdcxx_tr1,
- [AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- AC_TRY_COMPILE([
- #include &lt;tr1/array&gt;
- #include &lt;tr1/ccomplex&gt;
- #include &lt;tr1/cctype&gt;
- #include &lt;tr1/cfenv&gt;
- #include &lt;tr1/cfloat&gt;
- #include &lt;tr1/cinttypes&gt;
- #include &lt;tr1/climits&gt;
- #include &lt;tr1/cmath&gt;
- #include &lt;tr1/complex&gt;
- #include &lt;tr1/cstdarg&gt;
- #include &lt;tr1/cstdbool&gt;
- #include &lt;tr1/cstdint&gt;
- #include &lt;tr1/cstdio&gt;
- #include &lt;tr1/cstdlib&gt;
- #include &lt;tr1/ctgmath&gt;
- #include &lt;tr1/ctime&gt;
- #include &lt;tr1/cwchar&gt;
- #include &lt;tr1/cwctype&gt;
- #include &lt;tr1/functional&gt;
- #include &lt;tr1/memory&gt;
- #include &lt;tr1/random&gt;
- #include &lt;tr1/regex&gt;
- #include &lt;tr1/tuple&gt;
- #include &lt;tr1/type_traits&gt;
- #include &lt;tr1/unordered_set&gt;
- #include &lt;tr1/unordered_map&gt;
- #include &lt;tr1/utility&gt;
- ],,
- ac_cv_cxx_stdcxx_tr1=yes, ac_cv_cxx_stdcxx_tr1=no)
- AC_LANG_RESTORE
- ])
- if test "$ac_cv_cxx_stdcxx_tr1" = yes; then
- AC_DEFINE(STDCXX_TR1_HEADERS,,[Define if ISO C++ TR1 header files are present. ])
- fi
-])
-</pre><p>An alternative is to check just for specific TR1 includes, such as &lt;unordered_map&gt; and &lt;unordered_set&gt;.
-</p><pre class="programlisting">
-# AC_HEADER_TR1_UNORDERED_MAP
-AC_DEFUN([AC_HEADER_TR1_UNORDERED_MAP], [
- AC_CACHE_CHECK(for tr1/unordered_map,
- ac_cv_cxx_tr1_unordered_map,
- [AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- AC_TRY_COMPILE([#include &lt;tr1/unordered_map&gt;], [using std::tr1::unordered_map;],
- ac_cv_cxx_tr1_unordered_map=yes, ac_cv_cxx_tr1_unordered_map=no)
- AC_LANG_RESTORE
- ])
- if test "$ac_cv_cxx_tr1_unordered_map" = yes; then
- AC_DEFINE(HAVE_TR1_UNORDERED_MAP,,[Define if tr1/unordered_map is present. ])
- fi
-])
-</pre><pre class="programlisting">
-# AC_HEADER_TR1_UNORDERED_SET
-AC_DEFUN([AC_HEADER_TR1_UNORDERED_SET], [
- AC_CACHE_CHECK(for tr1/unordered_set,
- ac_cv_cxx_tr1_unordered_set,
- [AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- AC_TRY_COMPILE([#include &lt;tr1/unordered_set&gt;], [using std::tr1::unordered_set;],
- ac_cv_cxx_tr1_unordered_set=yes, ac_cv_cxx_tr1_unordered_set=no)
- AC_LANG_RESTORE
- ])
- if test "$ac_cv_cxx_tr1_unordered_set" = yes; then
- AC_DEFINE(HAVE_TR1_UNORDERED_SET,,[Define if tr1/unordered_set is present. ])
- fi
-])
-</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id511602"></a>
-Support for C++0x dialect.
-</h4></div></div></div><p>Check for baseline language coverage in the compiler for the C++0xstandard.
-</p><pre class="programlisting">
-# AC_COMPILE_STDCXX_OX
-AC_DEFUN([AC_COMPILE_STDCXX_0X], [
- AC_CACHE_CHECK(if g++ supports C++0x features without additional flags,
- ac_cv_cxx_compile_cxx0x_native,
- [AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- AC_TRY_COMPILE([
- template &lt;typename T&gt;
- struct check
- {
- static_assert(sizeof(int) &lt;= sizeof(T), "not big enough");
- };
-
- typedef check&lt;check&lt;bool&gt;&gt; right_angle_brackets;
-
- int a;
- decltype(a) b;
-
- typedef check&lt;int&gt; check_type;
- check_type c;
- check_type&amp;&amp; cr = c;],,
- ac_cv_cxx_compile_cxx0x_native=yes, ac_cv_cxx_compile_cxx0x_native=no)
- AC_LANG_RESTORE
- ])
-
- AC_CACHE_CHECK(if g++ supports C++0x features with -std=c++0x,
- ac_cv_cxx_compile_cxx0x_cxx,
- [AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=c++0x"
- AC_TRY_COMPILE([
- template &lt;typename T&gt;
- struct check
- {
- static_assert(sizeof(int) &lt;= sizeof(T), "not big enough");
- };
-
- typedef check&lt;check&lt;bool&gt;&gt; right_angle_brackets;
-
- int a;
- decltype(a) b;
-
- typedef check&lt;int&gt; check_type;
- check_type c;
- check_type&amp;&amp; cr = c;],,
- ac_cv_cxx_compile_cxx0x_cxx=yes, ac_cv_cxx_compile_cxx0x_cxx=no)
- CXXFLAGS="$ac_save_CXXFLAGS"
- AC_LANG_RESTORE
- ])
-
- AC_CACHE_CHECK(if g++ supports C++0x features with -std=gnu++0x,
- ac_cv_cxx_compile_cxx0x_gxx,
- [AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=gnu++0x"
- AC_TRY_COMPILE([
- template &lt;typename T&gt;
- struct check
- {
- static_assert(sizeof(int) &lt;= sizeof(T), "not big enough");
- };
-
- typedef check&lt;check&lt;bool&gt;&gt; right_angle_brackets;
-
- int a;
- decltype(a) b;
-
- typedef check&lt;int&gt; check_type;
- check_type c;
- check_type&amp;&amp; cr = c;],,
- ac_cv_cxx_compile_cxx0x_gxx=yes, ac_cv_cxx_compile_cxx0x_gxx=no)
- CXXFLAGS="$ac_save_CXXFLAGS"
- AC_LANG_RESTORE
- ])
-
- if test "$ac_cv_cxx_compile_cxx0x_native" = yes ||
- test "$ac_cv_cxx_compile_cxx0x_cxx" = yes ||
- test "$ac_cv_cxx_compile_cxx0x_gxx" = yes; then
- AC_DEFINE(HAVE_STDCXX_0X,,[Define if g++ supports C++0x features. ])
- fi
-])
-</pre><p>Check for library coverage of the C++0xstandard.
-</p><pre class="programlisting">
-# AC_HEADER_STDCXX_0X
-AC_DEFUN([AC_HEADER_STDCXX_0X], [
- AC_CACHE_CHECK(for ISO C++ 0x include files,
- ac_cv_cxx_stdcxx_0x,
- [AC_REQUIRE([AC_COMPILE_STDCXX_0X])
- AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=gnu++0x"
-
- AC_TRY_COMPILE([
- #include &lt;cassert&gt;
- #include &lt;ccomplex&gt;
- #include &lt;cctype&gt;
- #include &lt;cerrno&gt;
- #include &lt;cfenv&gt;
- #include &lt;cfloat&gt;
- #include &lt;cinttypes&gt;
- #include &lt;ciso646&gt;
- #include &lt;climits&gt;
- #include &lt;clocale&gt;
- #include &lt;cmath&gt;
- #include &lt;csetjmp&gt;
- #include &lt;csignal&gt;
- #include &lt;cstdarg&gt;
- #include &lt;cstdbool&gt;
- #include &lt;cstddef&gt;
- #include &lt;cstdint&gt;
- #include &lt;cstdio&gt;
- #include &lt;cstdlib&gt;
- #include &lt;cstring&gt;
- #include &lt;ctgmath&gt;
- #include &lt;ctime&gt;
- #include &lt;cwchar&gt;
- #include &lt;cwctype&gt;
-
- #include &lt;algorithm&gt;
- #include &lt;array&gt;
- #include &lt;bitset&gt;
- #include &lt;complex&gt;
- #include &lt;deque&gt;
- #include &lt;exception&gt;
- #include &lt;fstream&gt;
- #include &lt;functional&gt;
- #include &lt;iomanip&gt;
- #include &lt;ios&gt;
- #include &lt;iosfwd&gt;
- #include &lt;iostream&gt;
- #include &lt;istream&gt;
- #include &lt;iterator&gt;
- #include &lt;limits&gt;
- #include &lt;list&gt;
- #include &lt;locale&gt;
- #include &lt;map&gt;
- #include &lt;memory&gt;
- #include &lt;new&gt;
- #include &lt;numeric&gt;
- #include &lt;ostream&gt;
- #include &lt;queue&gt;
- #include &lt;random&gt;
- #include &lt;regex&gt;
- #include &lt;set&gt;
- #include &lt;sstream&gt;
- #include &lt;stack&gt;
- #include &lt;stdexcept&gt;
- #include &lt;streambuf&gt;
- #include &lt;string&gt;
- #include &lt;tuple&gt;
- #include &lt;typeinfo&gt;
- #include &lt;type_traits&gt;
- #include &lt;unordered_map&gt;
- #include &lt;unordered_set&gt;
- #include &lt;utility&gt;
- #include &lt;valarray&gt;
- #include &lt;vector&gt;
- ],,
- ac_cv_cxx_stdcxx_0x=yes, ac_cv_cxx_stdcxx_0x=no)
- AC_LANG_RESTORE
- CXXFLAGS="$ac_save_CXXFLAGS"
- ])
- if test "$ac_cv_cxx_stdcxx_0x" = yes; then
- AC_DEFINE(STDCXX_0X_HEADERS,,[Define if ISO C++ 0x header files are present. ])
- fi
-])
-</pre><p>As is the case for TR1 support, these autoconf macros can be made for a finer-grained, per-header-file check. For &lt;unordered_map&gt;
-</p><pre class="programlisting">
-# AC_HEADER_UNORDERED_MAP
-AC_DEFUN([AC_HEADER_UNORDERED_MAP], [
- AC_CACHE_CHECK(for unordered_map,
- ac_cv_cxx_unordered_map,
- [AC_REQUIRE([AC_COMPILE_STDCXX_0X])
- AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=gnu++0x"
- AC_TRY_COMPILE([#include &lt;unordered_map&gt;], [using std::unordered_map;],
- ac_cv_cxx_unordered_map=yes, ac_cv_cxx_unordered_map=no)
- CXXFLAGS="$ac_save_CXXFLAGS"
- AC_LANG_RESTORE
- ])
- if test "$ac_cv_cxx_unordered_map" = yes; then
- AC_DEFINE(HAVE_UNORDERED_MAP,,[Define if unordered_map is present. ])
- fi
-])
-</pre><pre class="programlisting">
-# AC_HEADER_UNORDERED_SET
-AC_DEFUN([AC_HEADER_UNORDERED_SET], [
- AC_CACHE_CHECK(for unordered_set,
- ac_cv_cxx_unordered_set,
- [AC_REQUIRE([AC_COMPILE_STDCXX_0X])
- AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
- ac_save_CXXFLAGS="$CXXFLAGS"
- CXXFLAGS="$CXXFLAGS -std=gnu++0x"
- AC_TRY_COMPILE([#include &lt;unordered_set&gt;], [using std::unordered_set;],
- ac_cv_cxx_unordered_set=yes, ac_cv_cxx_unordered_set=no)
- CXXFLAGS="$ac_save_CXXFLAGS"
- AC_LANG_RESTORE
- ])
- if test "$ac_cv_cxx_unordered_set" = yes; then
- AC_DEFINE(HAVE_UNORDERED_SET,,[Define if unordered_set is present. ])
- fi
-])
-</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id511679"></a>
- Container::iterator_type is not necessarily Container::value_type*
-</h4></div></div></div><p>
- This is a change in behavior from the previous version. Now, most
- <span class="type">iterator_type</span> typedefs in container classes are POD
- objects, not <span class="type">value_type</span> pointers.
-</p></div></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="backwards.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id511711"></a><p>[<abbr class="abbrev">
- kegel41
- </abbr>] <span class="title"><i>
- Migrating to GCC 4.1
- </i>. </span><span class="author"><span class="firstname">Dan</span> <span class="surname">Kegel</span>. </span><span class="biblioid">
- <a class="ulink" href="http://www.kegel.com/gcc/gcc4.html" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id511743"></a><p>[<abbr class="abbrev">
- kegel41
- </abbr>] <span class="title"><i>
- Building the Whole Debian Archive with GCC 4.1: A Summary
- </i>. </span><span class="author"><span class="firstname">Martin</span> <span class="surname">Michlmayr</span>. </span><span class="biblioid">
- <a class="ulink" href="http://lists.debian.org/debian-gcc/2006/03/msg00405.html" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id511776"></a><p>[<abbr class="abbrev">
- lbl32
- </abbr>] <span class="title"><i>
- Migration guide for GCC-3.2
- </i>. </span><span class="biblioid">
- <a class="ulink" href="http://annwm.lbl.gov/~leggett/Atlas/gcc-3.2.html" target="_top">
- </a>
- . </span></p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="api.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_porting.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="appendix_free.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">API Evolution and Deprecation History </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix C. 
- Free Software Needs Free Documentation
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bitmap_allocator.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bitmap_allocator.html
deleted file mode 100644
index 393e08b96..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bitmap_allocator.html
+++ /dev/null
@@ -1,340 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>bitmap_allocator</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; allocator&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="ext_allocators.html" title="Chapter 32. Allocators" /><link rel="prev" href="ext_allocators.html" title="Chapter 32. Allocators" /><link rel="next" href="ext_containers.html" title="Chapter 33. Containers" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">bitmap_allocator</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ext_allocators.html">Prev</a> </td><th width="60%" align="center">Chapter 32. Allocators</th><td width="20%" align="right"> <a accesskey="n" href="ext_containers.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.allocator.bitmap"></a>bitmap_allocator</h2></div></div></div><p>
-</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.bitmap.design"></a>Design</h3></div></div></div><p>
- As this name suggests, this allocator uses a bit-map to keep track
- of the used and unused memory locations for it's book-keeping
- purposes.
- </p><p>
- This allocator will make use of 1 single bit to keep track of
- whether it has been allocated or not. A bit 1 indicates free,
- while 0 indicates allocated. This has been done so that you can
- easily check a collection of bits for a free block. This kind of
- Bitmapped strategy works best for single object allocations, and
- with the STL type parameterized allocators, we do not need to
- choose any size for the block which will be represented by a
- single bit. This will be the size of the parameter around which
- the allocator has been parameterized. Thus, close to optimal
- performance will result. Hence, this should be used for node based
- containers which call the allocate function with an argument of 1.
- </p><p>
- The bitmapped allocator's internal pool is exponentially growing.
- Meaning that internally, the blocks acquired from the Free List
- Store will double every time the bitmapped allocator runs out of
- memory.
- </p><p>
- The macro <code class="literal">__GTHREADS</code> decides whether to use
- Mutex Protection around every allocation/deallocation. The state
- of the macro is picked up automatically from the gthr abstraction
- layer.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.bitmap.impl"></a>Implementation</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.free_list_store"></a>Free List Store</h4></div></div></div><p>
- The Free List Store (referred to as FLS for the remaining part of this
- document) is the Global memory pool that is shared by all instances of
- the bitmapped allocator instantiated for any type. This maintains a
- sorted order of all free memory blocks given back to it by the
- bitmapped allocator, and is also responsible for giving memory to the
- bitmapped allocator when it asks for more.
- </p><p>
- Internally, there is a Free List threshold which indicates the
- Maximum number of free lists that the FLS can hold internally
- (cache). Currently, this value is set at 64. So, if there are
- more than 64 free lists coming in, then some of them will be given
- back to the OS using operator delete so that at any given time the
- Free List's size does not exceed 64 entries. This is done because
- a Binary Search is used to locate an entry in a free list when a
- request for memory comes along. Thus, the run-time complexity of
- the search would go up given an increasing size, for 64 entries
- however, lg(64) == 6 comparisons are enough to locate the correct
- free list if it exists.
- </p><p>
- Suppose the free list size has reached it's threshold, then the
- largest block from among those in the list and the new block will
- be selected and given back to the OS. This is done because it
- reduces external fragmentation, and allows the OS to use the
- larger blocks later in an orderly fashion, possibly merging them
- later. Also, on some systems, large blocks are obtained via calls
- to mmap, so giving them back to free system resources becomes most
- important.
- </p><p>
- The function _S_should_i_give decides the policy that determines
- whether the current block of memory should be given to the
- allocator for the request that it has made. That's because we may
- not always have exact fits for the memory size that the allocator
- requests. We do this mainly to prevent external fragmentation at
- the cost of a little internal fragmentation. Now, the value of
- this internal fragmentation has to be decided by this function. I
- can see 3 possibilities right now. Please add more as and when you
- find better strategies.
- </p><div class="orderedlist"><ol type="1"><li><p>Equal size check. Return true only when the 2 blocks are of equal
-size.</p></li><li><p>Difference Threshold: Return true only when the _block_size is
-greater than or equal to the _required_size, and if the _BS is &gt; _RS
-by a difference of less than some THRESHOLD value, then return true,
-else return false. </p></li><li><p>Percentage Threshold. Return true only when the _block_size is
-greater than or equal to the _required_size, and if the _BS is &gt; _RS
-by a percentage of less than some THRESHOLD value, then return true,
-else return false.</p></li></ol></div><p>
- Currently, (3) is being used with a value of 36% Maximum wastage per
- Super Block.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.super_block"></a>Super Block</h4></div></div></div><p>
- A super block is the block of memory acquired from the FLS from
- which the bitmap allocator carves out memory for single objects
- and satisfies the user's requests. These super blocks come in
- sizes that are powers of 2 and multiples of 32
- (_Bits_Per_Block). Yes both at the same time! That's because the
- next super block acquired will be 2 times the previous one, and
- also all super blocks have to be multiples of the _Bits_Per_Block
- value.
- </p><p>
- How does it interact with the free list store?
- </p><p>
- The super block is contained in the FLS, and the FLS is responsible for
- getting / returning Super Bocks to and from the OS using operator new
- as defined by the C++ standard.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.super_block_data"></a>Super Block Data Layout</h4></div></div></div><p>
- Each Super Block will be of some size that is a multiple of the
- number of Bits Per Block. Typically, this value is chosen as
- Bits_Per_Byte x sizeof(size_t). On an x86 system, this gives the
- figure 8 x 4 = 32. Thus, each Super Block will be of size 32
- x Some_Value. This Some_Value is sizeof(value_type). For now, let
- it be called 'K'. Thus, finally, Super Block size is 32 x K bytes.
- </p><p>
- This value of 32 has been chosen because each size_t has 32-bits
- and Maximum use of these can be made with such a figure.
- </p><p>
- Consider a block of size 64 ints. In memory, it would look like this:
- (assume a 32-bit system where, size_t is a 32-bit entity).
- </p><div class="table"><a id="id435115"></a><p class="title"><b>Table 32.1. Bitmap Allocator Memory Map</b></p><div class="table-contents"><table summary="Bitmap Allocator Memory Map" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left">268</td><td align="left">0</td><td align="left">4294967295</td><td align="left">4294967295</td><td align="left">Data -&gt; Space for 64 ints</td></tr></tbody></table></div></div><br class="table-break" /><p>
- The first Column(268) represents the size of the Block in bytes as
- seen by the Bitmap Allocator. Internally, a global free list is
- used to keep track of the free blocks used and given back by the
- bitmap allocator. It is this Free List Store that is responsible
- for writing and managing this information. Actually the number of
- bytes allocated in this case would be: 4 + 4 + (4x2) + (64x4) =
- 272 bytes, but the first 4 bytes are an addition by the Free List
- Store, so the Bitmap Allocator sees only 268 bytes. These first 4
- bytes about which the bitmapped allocator is not aware hold the
- value 268.
- </p><p>
- What do the remaining values represent?</p><p>
- The 2nd 4 in the expression is the sizeof(size_t) because the
- Bitmapped Allocator maintains a used count for each Super Block,
- which is initially set to 0 (as indicated in the diagram). This is
- incremented every time a block is removed from this super block
- (allocated), and decremented whenever it is given back. So, when
- the used count falls to 0, the whole super block will be given
- back to the Free List Store.
- </p><p>
- The value 4294967295 represents the integer corresponding to the bit
- representation of all bits set: 11111111111111111111111111111111.
- </p><p>
- The 3rd 4x2 is size of the bitmap itself, which is the size of 32-bits
- x 2,
- which is 8-bytes, or 2 x sizeof(size_t).
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.max_wasted"></a>Maximum Wasted Percentage</h4></div></div></div><p>
- This has nothing to do with the algorithm per-se,
- only with some vales that must be chosen correctly to ensure that the
- allocator performs well in a real word scenario, and maintains a good
- balance between the memory consumption and the allocation/deallocation
- speed.
- </p><p>
- The formula for calculating the maximum wastage as a percentage:
- </p><p>
-(32 x k + 1) / (2 x (32 x k + 1 + 32 x c)) x 100.
- </p><p>
- where k is the constant overhead per node (e.g., for list, it is
- 8 bytes, and for map it is 12 bytes) and c is the size of the
- base type on which the map/list is instantiated. Thus, suppose the
- type1 is int and type2 is double, they are related by the relation
- sizeof(double) == 2*sizeof(int). Thus, all types must have this
- double size relation for this formula to work properly.
- </p><p>
- Plugging-in: For List: k = 8 and c = 4 (int and double), we get:
- 33.376%
- </p><p>
-For map/multimap: k = 12, and c = 4 (int and double), we get: 37.524%
- </p><p>
- Thus, knowing these values, and based on the sizeof(value_type), we may
- create a function that returns the Max_Wastage_Percentage for us to use.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.allocate"></a><code class="function">allocate</code></h4></div></div></div><p>
- The allocate function is specialized for single object allocation
- ONLY. Thus, ONLY if n == 1, will the bitmap_allocator's
- specialized algorithm be used. Otherwise, the request is satisfied
- directly by calling operator new.
- </p><p>
- Suppose n == 1, then the allocator does the following:
- </p><div class="orderedlist"><ol type="1"><li><p>
- Checks to see whether a free block exists somewhere in a region
- of memory close to the last satisfied request. If so, then that
- block is marked as allocated in the bit map and given to the
- user. If not, then (2) is executed.
- </p></li><li><p>
- Is there a free block anywhere after the current block right
- up to the end of the memory that we have? If so, that block is
- found, and the same procedure is applied as above, and
- returned to the user. If not, then (3) is executed.
- </p></li><li><p>
- Is there any block in whatever region of memory that we own
- free? This is done by checking
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- The use count for each super block, and if that fails then
- </p></li><li><p>
- The individual bit-maps for each super block.
- </p></li></ul></div><p>
- Note: Here we are never touching any of the memory that the
- user will be given, and we are confining all memory accesses
- to a small region of memory! This helps reduce cache
- misses. If this succeeds then we apply the same procedure on
- that bit-map as (1), and return that block of memory to the
- user. However, if this process fails, then we resort to (4).
- </p></li><li><p>
- This process involves Refilling the internal exponentially
- growing memory pool. The said effect is achieved by calling
- _S_refill_pool which does the following:
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- Gets more memory from the Global Free List of the Required
- size.
- </p></li><li><p>
- Adjusts the size for the next call to itself.
- </p></li><li><p>
- Writes the appropriate headers in the bit-maps.
- </p></li><li><p>
- Sets the use count for that super-block just allocated to 0
- (zero).
- </p></li><li><p>
- All of the above accounts to maintaining the basic invariant
- for the allocator. If the invariant is maintained, we are
- sure that all is well. Now, the same process is applied on
- the newly acquired free blocks, which are dispatched
- accordingly.
- </p></li></ul></div></li></ol></div><p>
-Thus, you can clearly see that the allocate function is nothing but a
-combination of the next-fit and first-fit algorithm optimized ONLY for
-single object allocations.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.deallocate"></a><code class="function">deallocate</code></h4></div></div></div><p>
- The deallocate function again is specialized for single objects ONLY.
- For all n belonging to &gt; 1, the operator delete is called without
- further ado, and the deallocate function returns.
- </p><p>
- However for n == 1, a series of steps are performed:
- </p><div class="orderedlist"><ol type="1"><li><p>
- We first need to locate that super-block which holds the memory
- location given to us by the user. For that purpose, we maintain
- a static variable _S_last_dealloc_index, which holds the index
- into the vector of block pairs which indicates the index of the
- last super-block from which memory was freed. We use this
- strategy in the hope that the user will deallocate memory in a
- region close to what he/she deallocated the last time around. If
- the check for belongs_to succeeds, then we determine the bit-map
- for the given pointer, and locate the index into that bit-map,
- and mark that bit as free by setting it.
- </p></li><li><p>
- If the _S_last_dealloc_index does not point to the memory block
- that we're looking for, then we do a linear search on the block
- stored in the vector of Block Pairs. This vector in code is
- called _S_mem_blocks. When the corresponding super-block is
- found, we apply the same procedure as we did for (1) to mark the
- block as free in the bit-map.
- </p></li></ol></div><p>
- Now, whenever a block is freed, the use count of that particular
- super block goes down by 1. When this use count hits 0, we remove
- that super block from the list of all valid super blocks stored in
- the vector. While doing this, we also make sure that the basic
- invariant is maintained by making sure that _S_last_request and
- _S_last_dealloc_index point to valid locations within the vector.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.questions"></a>Questions</h4></div></div></div><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="bitmap.impl.question.1"></a>1</h5></div></div></div><p>
-Q1) The "Data Layout" section is
-cryptic. I have no idea of what you are trying to say. Layout of what?
-The free-list? Each bitmap? The Super Block?
- </p><p>
- The layout of a Super Block of a given
-size. In the example, a super block of size 32 x 1 is taken. The
-general formula for calculating the size of a super block is
-32 x sizeof(value_type) x 2^n, where n ranges from 0 to 32 for 32-bit
-systems.
- </p></div><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="bitmap.impl.question.2"></a>2</h5></div></div></div><p>
- And since I just mentioned the
-term `each bitmap', what in the world is meant by it? What does each
-bitmap manage? How does it relate to the super block? Is the Super
-Block a bitmap as well?
- </p><p>
- Each bitmap is part of a Super Block which is made up of 3 parts
- as I have mentioned earlier. Re-iterating, 1. The use count,
- 2. The bit-map for that Super Block. 3. The actual memory that
- will be eventually given to the user. Each bitmap is a multiple
- of 32 in size. If there are 32 x (2^3) blocks of single objects
- to be given, there will be '32 x (2^3)' bits present. Each 32
- bits managing the allocated / free status for 32 blocks. Since
- each size_t contains 32-bits, one size_t can manage up to 32
- blocks' status. Each bit-map is made up of a number of size_t,
- whose exact number for a super-block of a given size I have just
- mentioned.
- </p></div><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="bitmap.impl.question.3"></a>3</h5></div></div></div><p>
- How do the allocate and deallocate functions work in regard to
- bitmaps?
- </p><p>
- The allocate and deallocate functions manipulate the bitmaps and
- have nothing to do with the memory that is given to the user. As
- I have earlier mentioned, a 1 in the bitmap's bit field
- indicates free, while a 0 indicates allocated. This lets us
- check 32 bits at a time to check whether there is at lease one
- free block in those 32 blocks by testing for equality with
- (0). Now, the allocate function will given a memory block find
- the corresponding bit in the bitmap, and will reset it (i.e.,
- make it re-set (0)). And when the deallocate function is called,
- it will again set that bit after locating it to indicate that
- that particular block corresponding to this bit in the bit-map
- is not being used by anyone, and may be used to satisfy future
- requests.
- </p><p>
- e.g.: Consider a bit-map of 64-bits as represented below:
- 1111111111111111111111111111111111111111111111111111111111111111
- </p><p>
- Now, when the first request for allocation of a single object
- comes along, the first block in address order is returned. And
- since the bit-maps in the reverse order to that of the address
- order, the last bit (LSB if the bit-map is considered as a
- binary word of 64-bits) is re-set to 0.
- </p><p>
- The bit-map now looks like this:
- 1111111111111111111111111111111111111111111111111111111111111110
- </p></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.locality"></a>Locality</h4></div></div></div><p>
- Another issue would be whether to keep the all bitmaps in a
- separate area in memory, or to keep them near the actual blocks
- that will be given out or allocated for the client. After some
- testing, I've decided to keep these bitmaps close to the actual
- blocks. This will help in 2 ways.
- </p><div class="orderedlist"><ol type="1"><li><p>Constant time access for the bitmap themselves, since no kind of
-look up will be needed to find the correct bitmap list or it's
-equivalent.</p></li><li><p>And also this would preserve the cache as far as possible.</p></li></ol></div><p>
- So in effect, this kind of an allocator might prove beneficial from a
- purely cache point of view. But this allocator has been made to try and
- roll out the defects of the node_allocator, wherein the nodes get
- skewed about in memory, if they are not returned in the exact reverse
- order or in the same order in which they were allocated. Also, the
- new_allocator's book keeping overhead is too much for small objects and
- single object allocations, though it preserves the locality of blocks
- very well when they are returned back to the allocator.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="bitmap.impl.grow_policy"></a>Overhead and Grow Policy</h4></div></div></div><p>
- Expected overhead per block would be 1 bit in memory. Also, once
- the address of the free list has been found, the cost for
- allocation/deallocation would be negligible, and is supposed to be
- constant time. For these very reasons, it is very important to
- minimize the linear time costs, which include finding a free list
- with a free block while allocating, and finding the corresponding
- free list for a block while deallocating. Therefore, I have
- decided that the growth of the internal pool for this allocator
- will be exponential as compared to linear for
- node_allocator. There, linear time works well, because we are
- mainly concerned with speed of allocation/deallocation and memory
- consumption, whereas here, the allocation/deallocation part does
- have some linear/logarithmic complexity components in it. Thus, to
- try and minimize them would be a good thing to do at the cost of a
- little bit of memory.
- </p><p>
- Another thing to be noted is the pool size will double every time
- the internal pool gets exhausted, and all the free blocks have
- been given away. The initial size of the pool would be
- sizeof(size_t) x 8 which is the number of bits in an integer,
- which can fit exactly in a CPU register. Hence, the term given is
- exponential growth of the internal pool.
- </p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ext_allocators.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ext_allocators.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ext_containers.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 32. Allocators </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 33. Containers</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bitset.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bitset.html
deleted file mode 100644
index fcdba6d23..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bitset.html
+++ /dev/null
@@ -1,105 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>bitset</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="associative.html" title="Chapter 17. Associative" /><link rel="prev" href="associative.html" title="Chapter 17. Associative" /><link rel="next" href="containers_and_c.html" title="Chapter 18. Interacting with C" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">bitset</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="associative.html">Prev</a> </td><th width="60%" align="center">Chapter 17. Associative</th><td width="20%" align="right"> <a accesskey="n" href="containers_and_c.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="containers.associative.bitset"></a>bitset</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="associative.bitset.size_variable"></a>Size Variable</h3></div></div></div><p>
- No, you cannot write code of the form
- </p><pre class="programlisting">
- #include &lt;bitset&gt;
-
- void foo (size_t n)
- {
- std::bitset&lt;n&gt; bits;
- ....
- }
- </pre><p>
- because <code class="code">n</code> must be known at compile time. Your
- compiler is correct; it is not a bug. That's the way templates
- work. (Yes, it <span class="emphasis"><em>is</em></span> a feature.)
- </p><p>
- There are a couple of ways to handle this kind of thing. Please
- consider all of them before passing judgement. They include, in
- no particular order:
- </p><div class="itemizedlist"><ul type="disc"><li><p>A very large N in <code class="code">bitset&lt;N&gt;</code>.</p></li><li><p>A container&lt;bool&gt;.</p></li><li><p>Extremely weird solutions.</p></li></ul></div><p>
- <span class="emphasis"><em>A very large N in
- <code class="code">bitset&lt;N&gt;</code>.  </em></span> It has been
- pointed out a few times in newsgroups that N bits only takes up
- (N/8) bytes on most systems, and division by a factor of eight is
- pretty impressive when speaking of memory. Half a megabyte given
- over to a bitset (recall that there is zero space overhead for
- housekeeping info; it is known at compile time exactly how large
- the set is) will hold over four million bits. If you're using
- those bits as status flags (e.g.,
- “<span class="quote">changed</span>”/“<span class="quote">unchanged</span>” flags), that's a
- <span class="emphasis"><em>lot</em></span> of state.
- </p><p>
- You can then keep track of the “<span class="quote">maximum bit used</span>”
- during some testing runs on representative data, make note of how
- many of those bits really need to be there, and then reduce N to
- a smaller number. Leave some extra space, of course. (If you
- plan to write code like the incorrect example above, where the
- bitset is a local variable, then you may have to talk your
- compiler into allowing that much stack space; there may be zero
- space overhead, but it's all allocated inside the object.)
- </p><p>
- <span class="emphasis"><em>A container&lt;bool&gt;.  </em></span> The
- Committee made provision for the space savings possible with that
- (N/8) usage previously mentioned, so that you don't have to do
- wasteful things like <code class="code">Container&lt;char&gt;</code> or
- <code class="code">Container&lt;short int&gt;</code>. Specifically,
- <code class="code">vector&lt;bool&gt;</code> is required to be specialized for
- that space savings.
- </p><p>
- The problem is that <code class="code">vector&lt;bool&gt;</code> doesn't
- behave like a normal vector anymore. There have been recent
- journal articles which discuss the problems (the ones by Herb
- Sutter in the May and July/August 1999 issues of C++ Report cover
- it well). Future revisions of the ISO C++ Standard will change
- the requirement for <code class="code">vector&lt;bool&gt;</code>
- specialization. In the meantime, <code class="code">deque&lt;bool&gt;</code>
- is recommended (although its behavior is sane, you probably will
- not get the space savings, but the allocation scheme is different
- than that of vector).
- </p><p>
- <span class="emphasis"><em>Extremely weird solutions.  </em></span> If
- you have access to the compiler and linker at runtime, you can do
- something insane, like figuring out just how many bits you need,
- then writing a temporary source code file. That file contains an
- instantiation of <code class="code">bitset</code> for the required number of
- bits, inside some wrapper functions with unchanging signatures.
- Have your program then call the compiler on that file using
- Position Independent Code, then open the newly-created object
- file and load those wrapper functions. You'll have an
- instantiation of <code class="code">bitset&lt;N&gt;</code> for the exact
- <code class="code">N</code> that you need at the time. Don't forget to delete
- the temporary files. (Yes, this <span class="emphasis"><em>can</em></span> be, and
- <span class="emphasis"><em>has been</em></span>, done.)
- </p><p>
- This would be the approach of either a visionary genius or a
- raving lunatic, depending on your programming and management
- style. Probably the latter.
- </p><p>
- Which of the above techniques you use, if any, are up to you and
- your intended application. Some time/space profiling is
- indicated if it really matters (don't just guess). And, if you
- manage to do anything along the lines of the third category, the
- author would love to hear from you...
- </p><p>
- Also note that the implementation of bitset used in libstdc++ has
- <a class="ulink" href="../ext/sgiexts.html#ch23" target="_top">some extensions</a>.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="associative.bitset.type_string"></a>Type String</h3></div></div></div><p>
- </p><p>
- Bitmasks do not take char* nor const char* arguments in their
- constructors. This is something of an accident, but you can read
- about the problem: follow the library's “<span class="quote">Links</span>” from
- the homepage, and from the C++ information “<span class="quote">defect
- reflector</span>” link, select the library issues list. Issue
- number 116 describes the problem.
- </p><p>
- For now you can simply make a temporary string object using the
- constructor expression:
- </p><pre class="programlisting">
- std::bitset&lt;5&gt; b ( std::string(“<span class="quote">10110</span>”) );
- </pre><p>
- instead of
- </p><pre class="programlisting">
- std::bitset&lt;5&gt; b ( “<span class="quote">10110</span>” ); // invalid
- </pre></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="associative.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="associative.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="containers_and_c.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 17. Associative </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 18. Interacting with C</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01ix01.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01ix01.html
deleted file mode 100644
index 1ce1d3917..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01ix01.html
+++ /dev/null
@@ -1,48 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Index</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="appendix_gfdl.html" title="Appendix E. GNU Free Documentation License" /><link rel="next" href="../bk02.html" title="" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Index</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="appendix_gfdl.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="../bk02.html">Next</a></td></tr></table><hr /></div><div class="index"><div class="titlepage"><div><div><h2 class="title"><a id="id510885"></a>Index</h2></div></div></div><div class="index"><div class="indexdiv"><h3>A</h3><dl><dt>Algorithms, <a class="indexterm" href="algorithms.html">
- Algorithms
-
-</a></dt><dt>Appendix</dt><dd><dl><dt>Contributing, <a class="indexterm" href="appendix_contributing.html">
- Contributing
-
-</a></dt><dt>Free Documentation, <a class="indexterm" href="appendix_free.html">
- Free Software Needs Free Documentation
-
-</a></dt><dt>Porting and Maintenance, <a class="indexterm" href="appendix_porting.html">
- Porting and Maintenance
-
-</a></dt></dl></dd></dl></div><div class="indexdiv"><h3>C</h3><dl><dt>Containers, <a class="indexterm" href="containers.html">
- Containers
-
-</a></dt></dl></div><div class="indexdiv"><h3>D</h3><dl><dt>Diagnostics, <a class="indexterm" href="diagnostics.html">
- Diagnostics
-
-</a></dt></dl></div><div class="indexdiv"><h3>E</h3><dl><dt>Extensions, <a class="indexterm" href="extensions.html">
- Extensions
-
-</a></dt></dl></div><div class="indexdiv"><h3>I</h3><dl><dt>Input and Output, <a class="indexterm" href="io.html">
- Input and Output
-
-</a></dt><dt>Introduction, <a class="indexterm" href="intro.html">
- Introduction
-
-</a></dt><dt>Iterators, <a class="indexterm" href="iterators.html">
- Iterators
-
-</a></dt></dl></div><div class="indexdiv"><h3>L</h3><dl><dt>Localization, <a class="indexterm" href="localization.html">
- Localization
-
-</a></dt></dl></div><div class="indexdiv"><h3>N</h3><dl><dt>Numerics, <a class="indexterm" href="numerics.html">
- Numerics
-
-</a></dt></dl></div><div class="indexdiv"><h3>S</h3><dl><dt>Strings, <a class="indexterm" href="strings.html">
- Strings
-
-</a></dt><dt>Support, <a class="indexterm" href="support.html">
- Support
-
-</a></dt></dl></div><div class="indexdiv"><h3>U</h3><dl><dt>Utilities, <a class="indexterm" href="utilities.html">
- Utilities
-
-</a></dt></dl></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="appendix_gfdl.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="../bk02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Appendix E. GNU Free Documentation License </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt02ch04s02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt02ch04s02.html
deleted file mode 100644
index e7fa31a2a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt02ch04s02.html
+++ /dev/null
@@ -1,49 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Numeric Properties</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="fundamental_types.html" title="Chapter 4. Types" /><link rel="prev" href="fundamental_types.html" title="Chapter 4. Types" /><link rel="next" href="bk01pt02ch04s03.html" title="NULL" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Numeric Properties</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="fundamental_types.html">Prev</a> </td><th width="60%" align="center">Chapter 4. Types</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt02ch04s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.support.types.numeric_limits"></a>Numeric Properties</h2></div></div></div><p>
- The header <code class="filename">limits</code> defines
- traits classes to give access to various implementation
- defined-aspects of the fundamental types. The traits classes --
- fourteen in total -- are all specializations of the template class
- <code class="classname">numeric_limits</code>, documented <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/structstd_1_1numeric__limits.html" target="_top">here</a>
- and defined as follows:
- </p><pre class="programlisting">
- template&lt;typename T&gt;
- struct class
- {
- static const bool is_specialized;
- static T max() throw();
- static T min() throw();
-
- static const int digits;
- static const int digits10;
- static const bool is_signed;
- static const bool is_integer;
- static const bool is_exact;
- static const int radix;
- static T epsilon() throw();
- static T round_error() throw();
-
- static const int min_exponent;
- static const int min_exponent10;
- static const int max_exponent;
- static const int max_exponent10;
-
- static const bool has_infinity;
- static const bool has_quiet_NaN;
- static const bool has_signaling_NaN;
- static const float_denorm_style has_denorm;
- static const bool has_denorm_loss;
- static T infinity() throw();
- static T quiet_NaN() throw();
- static T denorm_min() throw();
-
- static const bool is_iec559;
- static const bool is_bounded;
- static const bool is_modulo;
-
- static const bool traps;
- static const bool tinyness_before;
- static const float_round_style round_style;
- };
- </pre></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="fundamental_types.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="fundamental_types.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt02ch04s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 4. Types </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> NULL</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt02ch04s03.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt02ch04s03.html
deleted file mode 100644
index f8db0099c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt02ch04s03.html
+++ /dev/null
@@ -1,29 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>NULL</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="fundamental_types.html" title="Chapter 4. Types" /><link rel="prev" href="bk01pt02ch04s02.html" title="Numeric Properties" /><link rel="next" href="dynamic_memory.html" title="Chapter 5. Dynamic Memory" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">NULL</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt02ch04s02.html">Prev</a> </td><th width="60%" align="center">Chapter 4. Types</th><td width="20%" align="right"> <a accesskey="n" href="dynamic_memory.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.support.types.null"></a>NULL</h2></div></div></div><p>
- The only change that might affect people is the type of
- <code class="constant">NULL</code>: while it is required to be a macro,
- the definition of that macro is <span class="emphasis"><em>not</em></span> allowed
- to be <code class="constant">(void*)0</code>, which is often used in C.
- </p><p>
- For <span class="command"><strong>g++</strong></span>, <code class="constant">NULL</code> is
- </p><pre class="programlisting">#define</pre><p>'d to be
- <code class="constant">__null</code>, a magic keyword extension of
- <span class="command"><strong>g++</strong></span>.
- </p><p>
- The biggest problem of #defining <code class="constant">NULL</code> to be
- something like “<span class="quote">0L</span>” is that the compiler will view
- that as a long integer before it views it as a pointer, so
- overloading won't do what you expect. (This is why
- <span class="command"><strong>g++</strong></span> has a magic extension, so that
- <code class="constant">NULL</code> is always a pointer.)
- </p><p>In his book <a class="ulink" href="http://www.awprofessional.com/titles/0-201-92488-9/" target="_top"><span class="emphasis"><em>Effective
- C++</em></span></a>, Scott Meyers points out that the best way
- to solve this problem is to not overload on pointer-vs-integer
- types to begin with. He also offers a way to make your own magic
- <code class="constant">NULL</code> that will match pointers before it
- matches integers.
- </p><p>See
- <a class="ulink" href="http://www.awprofessional.com/titles/0-201-31015-5/" target="_top">the
- Effective C++ CD example</a>
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt02ch04s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="fundamental_types.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="dynamic_memory.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Numeric Properties </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 5. Dynamic Memory</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt02pr01.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt02pr01.html
deleted file mode 100644
index 54bec9472..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt02pr01.html
+++ /dev/null
@@ -1,17 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="support.html" title="Part II.  Support" /><link rel="prev" href="support.html" title="Part II.  Support" /><link rel="next" href="fundamental_types.html" title="Chapter 4. Types" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="support.html">Prev</a> </td><th width="60%" align="center">Part II. 
- Support
-
-</th><td width="20%" align="right"> <a accesskey="n" href="fundamental_types.html">Next</a></td></tr></table><hr /></div><div class="preface" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="id425347"></a></h2></div></div></div><p>
- This part deals with the functions called and objects created
- automatically during the course of a program's existence.
- </p><p>
- While we can't reproduce the contents of the Standard here (you
- need to get your own copy from your nation's member body; see our
- homepage for help), we can mention a couple of changes in what
- kind of support a C++ program gets from the Standard Library.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="support.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="support.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="fundamental_types.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part II. 
- Support
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 4. Types</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt03ch07s02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt03ch07s02.html
deleted file mode 100644
index e58c3f9b5..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt03ch07s02.html
+++ /dev/null
@@ -1,20 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Adding Data to Exceptions</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="exceptions.html" title="Chapter 7. Exceptions" /><link rel="prev" href="exceptions.html" title="Chapter 7. Exceptions" /><link rel="next" href="bk01pt03ch07s03.html" title="Cancellation" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Adding Data to Exceptions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="exceptions.html">Prev</a> </td><th width="60%" align="center">Chapter 7. Exceptions</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt03ch07s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.diagnostics.exceptions.data"></a>Adding Data to Exceptions</h2></div></div></div><p>
- The standard exception classes carry with them a single string as
- data (usually describing what went wrong or where the 'throw' took
- place). It's good to remember that you can add your own data to
- these exceptions when extending the hierarchy:
- </p><pre class="programlisting">
- struct My_Exception : public std::runtime_error
- {
- public:
- My_Exception (const string&amp; whatarg)
- : std::runtime_error(whatarg), e(errno), id(GetDataBaseID()) { }
- int errno_at_time_of_throw() const { return e; }
- DBID id_of_thing_that_threw() const { return id; }
- protected:
- int e;
- DBID id; // some user-defined type
- };
- </pre></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="exceptions.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="exceptions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt03ch07s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 7. Exceptions </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Cancellation</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt03ch07s03.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt03ch07s03.html
deleted file mode 100644
index 36d3d762c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt03ch07s03.html
+++ /dev/null
@@ -1,4 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Cancellation</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="exceptions.html" title="Chapter 7. Exceptions" /><link rel="prev" href="bk01pt03ch07s02.html" title="Adding Data to Exceptions" /><link rel="next" href="bk01pt03ch08.html" title="Chapter 8. Concept Checking" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Cancellation</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt03ch07s02.html">Prev</a> </td><th width="60%" align="center">Chapter 7. Exceptions</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt03ch08.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.diagnostics.exceptions.cancellation"></a>Cancellation</h2></div></div></div><p>
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt03ch07s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="exceptions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt03ch08.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Adding Data to Exceptions </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 8. Concept Checking</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt03ch08.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt03ch08.html
deleted file mode 100644
index 26a4b75fb..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt03ch08.html
+++ /dev/null
@@ -1,45 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 8. Concept Checking</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="diagnostics.html" title="Part III.  Diagnostics" /><link rel="prev" href="bk01pt03ch07s03.html" title="Cancellation" /><link rel="next" href="utilities.html" title="Part IV.  Utilities" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 8. Concept Checking</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt03ch07s03.html">Prev</a> </td><th width="60%" align="center">Part III. 
- Diagnostics
-
-</th><td width="20%" align="right"> <a accesskey="n" href="utilities.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.diagnostics.concept_checking"></a>Chapter 8. Concept Checking</h2></div></div></div><p>
- In 1999, SGI added “<span class="quote">concept checkers</span>” to their
- implementation of the STL: code which checked the template
- parameters of instantiated pieces of the STL, in order to insure
- that the parameters being used met the requirements of the
- standard. For example, the Standard requires that types passed as
- template parameters to <code class="classname">vector</code> be
- "Assignable" (which means what you think it means). The
- checking was done during compilation, and none of the code was
- executed at runtime.
- </p><p>
- Unfortunately, the size of the compiler files grew significantly
- as a result. The checking code itself was cumbersome. And bugs
- were found in it on more than one occasion.
- </p><p>
- The primary author of the checking code, Jeremy Siek, had already
- started work on a replacement implementation. The new code has been
- formally reviewed and accepted into
- <a class="ulink" href="http://www.boost.org/libs/concept_check/concept_check.htm" target="_top">the
- Boost libraries</a>, and we are pleased to incorporate it into the
- GNU C++ library.
- </p><p>
- The new version imposes a much smaller space overhead on the generated
- object file. The checks are also cleaner and easier to read and
- understand.
- </p><p>
- They are off by default for all versions of GCC.
- They can be enabled at configure time with
- <a class="ulink" href="../configopts.html" target="_top"><code class="literal">--enable-concept-checks</code></a>.
- You can enable them on a per-translation-unit basis with
- <code class="literal">-D_GLIBCXX_CONCEPT_CHECKS</code>.
- </p><p>
- Please note that the upcoming C++ standard has first-class
- support for template parameter constraints based on concepts in the core
- language. This will obviate the need for the library-simulated concept
- checking described above.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt03ch07s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="diagnostics.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="utilities.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Cancellation </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part IV. 
- Utilities
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13.html
deleted file mode 100644
index 07535c3c5..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13.html
+++ /dev/null
@@ -1,95 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 13. String Classes</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="strings.html" title="Part V.  Strings" /><link rel="prev" href="strings.html" title="Part V.  Strings" /><link rel="next" href="bk01pt05ch13s02.html" title="Case Sensitivity" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 13. String Classes</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="strings.html">Prev</a> </td><th width="60%" align="center">Part V. 
- Strings
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt05ch13s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.strings.string"></a>Chapter 13. String Classes</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt05ch13.html#strings.string.simple">Simple Transformations</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s02.html">Case Sensitivity</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s03.html">Arbitrary Character Types</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s04.html">Tokenizing</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s05.html">Shrink to Fit</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s06.html">CString (MFC)</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="strings.string.simple"></a>Simple Transformations</h2></div></div></div><p>
- Here are Standard, simple, and portable ways to perform common
- transformations on a <code class="code">string</code> instance, such as
- "convert to all upper case." The word transformations
- is especially apt, because the standard template function
- <code class="code">transform&lt;&gt;</code> is used.
- </p><p>
- This code will go through some iterations. Here's a simple
- version:
- </p><pre class="programlisting">
- #include &lt;string&gt;
- #include &lt;algorithm&gt;
- #include &lt;cctype&gt; // old &lt;ctype.h&gt;
-
- struct ToLower
- {
- char operator() (char c) const { return std::tolower(c); }
- };
-
- struct ToUpper
- {
- char operator() (char c) const { return std::toupper(c); }
- };
-
- int main()
- {
- std::string s ("Some Kind Of Initial Input Goes Here");
-
- // Change everything into upper case
- std::transform (s.begin(), s.end(), s.begin(), ToUpper());
-
- // Change everything into lower case
- std::transform (s.begin(), s.end(), s.begin(), ToLower());
-
- // Change everything back into upper case, but store the
- // result in a different string
- std::string capital_s;
- capital_s.resize(s.size());
- std::transform (s.begin(), s.end(), capital_s.begin(), ToUpper());
- }
- </pre><p>
- <span class="emphasis"><em>Note</em></span> that these calls all
- involve the global C locale through the use of the C functions
- <code class="code">toupper/tolower</code>. This is absolutely guaranteed to work --
- but <span class="emphasis"><em>only</em></span> if the string contains <span class="emphasis"><em>only</em></span> characters
- from the basic source character set, and there are <span class="emphasis"><em>only</em></span>
- 96 of those. Which means that not even all English text can be
- represented (certain British spellings, proper names, and so forth).
- So, if all your input forevermore consists of only those 96
- characters (hahahahahaha), then you're done.
- </p><p><span class="emphasis"><em>Note</em></span> that the
- <code class="code">ToUpper</code> and <code class="code">ToLower</code> function objects
- are needed because <code class="code">toupper</code> and <code class="code">tolower</code>
- are overloaded names (declared in <code class="code">&lt;cctype&gt;</code> and
- <code class="code">&lt;locale&gt;</code>) so the template-arguments for
- <code class="code">transform&lt;&gt;</code> cannot be deduced, as explained in
- <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-11/msg00180.html" target="_top">this
- message</a>.
-
- At minimum, you can write short wrappers like
- </p><pre class="programlisting">
- char toLower (char c)
- {
- return std::tolower(c);
- } </pre><p>The correct method is to use a facet for a particular locale
- and call its conversion functions. These are discussed more in
- Chapter 22; the specific part is
- <a class="ulink" href="../22_locale/howto.html#7" target="_top">Correct Transformations</a>,
- which shows the final version of this code. (Thanks to James Kanze
- for assistance and suggestions on all of this.)
- </p><p>Another common operation is trimming off excess whitespace. Much
- like transformations, this task is trivial with the use of string's
- <code class="code">find</code> family. These examples are broken into multiple
- statements for readability:
- </p><pre class="programlisting">
- std::string str (" \t blah blah blah \n ");
-
- // trim leading whitespace
- string::size_type notwhite = str.find_first_not_of(" \t\n");
- str.erase(0,notwhite);
-
- // trim trailing whitespace
- notwhite = str.find_last_not_of(" \t\n");
- str.erase(notwhite+1); </pre><p>Obviously, the calls to <code class="code">find</code> could be inserted directly
- into the calls to <code class="code">erase</code>, in case your compiler does not
- optimize named temporaries out of existence.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="strings.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="strings.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt05ch13s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part V. 
- Strings
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Case Sensitivity</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s02.html
deleted file mode 100644
index c71af4b5e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s02.html
+++ /dev/null
@@ -1,40 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Case Sensitivity</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /><link rel="prev" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /><link rel="next" href="bk01pt05ch13s03.html" title="Arbitrary Character Types" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Case Sensitivity</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt05ch13.html">Prev</a> </td><th width="60%" align="center">Chapter 13. String Classes</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt05ch13s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="strings.string.case"></a>Case Sensitivity</h2></div></div></div><p>
- </p><p>The well-known-and-if-it-isn't-well-known-it-ought-to-be
- <a class="ulink" href="http://www.gotw.ca/gotw/" target="_top">Guru of the Week</a>
- discussions held on Usenet covered this topic in January of 1998.
- Briefly, the challenge was, “<span class="quote">write a 'ci_string' class which
- is identical to the standard 'string' class, but is
- case-insensitive in the same way as the (common but nonstandard)
- C function stricmp()</span>”.
- </p><pre class="programlisting">
- ci_string s( "AbCdE" );
-
- // case insensitive
- assert( s == "abcde" );
- assert( s == "ABCDE" );
-
- // still case-preserving, of course
- assert( strcmp( s.c_str(), "AbCdE" ) == 0 );
- assert( strcmp( s.c_str(), "abcde" ) != 0 ); </pre><p>The solution is surprisingly easy. The original answer was
- posted on Usenet, and a revised version appears in Herb Sutter's
- book <span class="emphasis"><em>Exceptional C++</em></span> and on his website as <a class="ulink" href="http://www.gotw.ca/gotw/029.htm" target="_top">GotW 29</a>.
- </p><p>See? Told you it was easy!</p><p>
- <span class="emphasis"><em>Added June 2000:</em></span> The May 2000 issue of C++
- Report contains a fascinating <a class="ulink" href="http://lafstern.org/matt/col2_new.pdf" target="_top"> article</a> by
- Matt Austern (yes, <span class="emphasis"><em>the</em></span> Matt Austern) on why
- case-insensitive comparisons are not as easy as they seem, and
- why creating a class is the <span class="emphasis"><em>wrong</em></span> way to go
- about it in production code. (The GotW answer mentions one of
- the principle difficulties; his article mentions more.)
- </p><p>Basically, this is "easy" only if you ignore some things,
- things which may be too important to your program to ignore. (I chose
- to ignore them when originally writing this entry, and am surprised
- that nobody ever called me on it...) The GotW question and answer
- remain useful instructional tools, however.
- </p><p><span class="emphasis"><em>Added September 2000:</em></span> James Kanze provided a link to a
- <a class="ulink" href="http://www.unicode.org/unicode/reports/tr21/" target="_top">Unicode
- Technical Report discussing case handling</a>, which provides some
- very good information.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt05ch13.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt05ch13.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt05ch13s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 13. String Classes </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Arbitrary Character Types</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s03.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s03.html
deleted file mode 100644
index 3a21fa7d8..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s03.html
+++ /dev/null
@@ -1,57 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Arbitrary Character Types</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /><link rel="prev" href="bk01pt05ch13s02.html" title="Case Sensitivity" /><link rel="next" href="bk01pt05ch13s04.html" title="Tokenizing" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Arbitrary Character Types</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt05ch13s02.html">Prev</a> </td><th width="60%" align="center">Chapter 13. String Classes</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt05ch13s04.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="strings.string.character_types"></a>Arbitrary Character Types</h2></div></div></div><p>
- </p><p>The <code class="code">std::basic_string</code> is tantalizingly general, in that
- it is parameterized on the type of the characters which it holds.
- In theory, you could whip up a Unicode character class and instantiate
- <code class="code">std::basic_string&lt;my_unicode_char&gt;</code>, or assuming
- that integers are wider than characters on your platform, maybe just
- declare variables of type <code class="code">std::basic_string&lt;int&gt;</code>.
- </p><p>That's the theory. Remember however that basic_string has additional
- type parameters, which take default arguments based on the character
- type (called <code class="code">CharT</code> here):
- </p><pre class="programlisting">
- template &lt;typename CharT,
- typename Traits = char_traits&lt;CharT&gt;,
- typename Alloc = allocator&lt;CharT&gt; &gt;
- class basic_string { .... };</pre><p>Now, <code class="code">allocator&lt;CharT&gt;</code> will probably Do The Right
- Thing by default, unless you need to implement your own allocator
- for your characters.
- </p><p>But <code class="code">char_traits</code> takes more work. The char_traits
- template is <span class="emphasis"><em>declared</em></span> but not <span class="emphasis"><em>defined</em></span>.
- That means there is only
- </p><pre class="programlisting">
- template &lt;typename CharT&gt;
- struct char_traits
- {
- static void foo (type1 x, type2 y);
- ...
- };</pre><p>and functions such as char_traits&lt;CharT&gt;::foo() are not
- actually defined anywhere for the general case. The C++ standard
- permits this, because writing such a definition to fit all possible
- CharT's cannot be done.
- </p><p>The C++ standard also requires that char_traits be specialized for
- instantiations of <code class="code">char</code> and <code class="code">wchar_t</code>, and it
- is these template specializations that permit entities like
- <code class="code">basic_string&lt;char,char_traits&lt;char&gt;&gt;</code> to work.
- </p><p>If you want to use character types other than char and wchar_t,
- such as <code class="code">unsigned char</code> and <code class="code">int</code>, you will
- need suitable specializations for them. For a time, in earlier
- versions of GCC, there was a mostly-correct implementation that
- let programmers be lazy but it broke under many situations, so it
- was removed. GCC 3.4 introduced a new implementation that mostly
- works and can be specialized even for <code class="code">int</code> and other
- built-in types.
- </p><p>If you want to use your own special character class, then you have
- <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00163.html" target="_top">a lot
- of work to do</a>, especially if you with to use i18n features
- (facets require traits information but don't have a traits argument).
- </p><p>Another example of how to specialize char_traits was given <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00260.html" target="_top">on the
- mailing list</a> and at a later date was put into the file <code class="code">
- include/ext/pod_char_traits.h</code>. We agree
- that the way it's used with basic_string (scroll down to main())
- doesn't look nice, but that's because <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00236.html" target="_top">the
- nice-looking first attempt</a> turned out to <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00242.html" target="_top">not
- be conforming C++</a>, due to the rule that CharT must be a POD.
- (See how tricky this is?)
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt05ch13s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt05ch13.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt05ch13s04.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Case Sensitivity </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Tokenizing</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s04.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s04.html
deleted file mode 100644
index 0ae02e162..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s04.html
+++ /dev/null
@@ -1,85 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Tokenizing</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /><link rel="prev" href="bk01pt05ch13s03.html" title="Arbitrary Character Types" /><link rel="next" href="bk01pt05ch13s05.html" title="Shrink to Fit" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Tokenizing</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt05ch13s03.html">Prev</a> </td><th width="60%" align="center">Chapter 13. String Classes</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt05ch13s05.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="strings.string.token"></a>Tokenizing</h2></div></div></div><p>
- </p><p>The Standard C (and C++) function <code class="code">strtok()</code> leaves a lot to
- be desired in terms of user-friendliness. It's unintuitive, it
- destroys the character string on which it operates, and it requires
- you to handle all the memory problems. But it does let the client
- code decide what to use to break the string into pieces; it allows
- you to choose the "whitespace," so to speak.
- </p><p>A C++ implementation lets us keep the good things and fix those
- annoyances. The implementation here is more intuitive (you only
- call it once, not in a loop with varying argument), it does not
- affect the original string at all, and all the memory allocation
- is handled for you.
- </p><p>It's called stringtok, and it's a template function. Sources are
- as below, in a less-portable form than it could be, to keep this
- example simple (for example, see the comments on what kind of
- string it will accept).
- </p><pre class="programlisting">
-#include &lt;string&gt;
-template &lt;typename Container&gt;
-void
-stringtok(Container &amp;container, string const &amp;in,
- const char * const delimiters = " \t\n")
-{
- const string::size_type len = in.length();
- string::size_type i = 0;
-
- while (i &lt; len)
- {
- // Eat leading whitespace
- i = in.find_first_not_of(delimiters, i);
- if (i == string::npos)
- return; // Nothing left but white space
-
- // Find the end of the token
- string::size_type j = in.find_first_of(delimiters, i);
-
- // Push token
- if (j == string::npos)
- {
- container.push_back(in.substr(i));
- return;
- }
- else
- container.push_back(in.substr(i, j-i));
-
- // Set up for next loop
- i = j + 1;
- }
-}
-</pre><p>
- The author uses a more general (but less readable) form of it for
- parsing command strings and the like. If you compiled and ran this
- code using it:
- </p><pre class="programlisting">
- std::list&lt;string&gt; ls;
- stringtok (ls, " this \t is\t\n a test ");
- for (std::list&lt;string&gt;const_iterator i = ls.begin();
- i != ls.end(); ++i)
- {
- std::cerr &lt;&lt; ':' &lt;&lt; (*i) &lt;&lt; ":\n";
- } </pre><p>You would see this as output:
- </p><pre class="programlisting">
- :this:
- :is:
- :a:
- :test: </pre><p>with all the whitespace removed. The original <code class="code">s</code> is still
- available for use, <code class="code">ls</code> will clean up after itself, and
- <code class="code">ls.size()</code> will return how many tokens there were.
- </p><p>As always, there is a price paid here, in that stringtok is not
- as fast as strtok. The other benefits usually outweigh that, however.
- <a class="ulink" href="stringtok_std_h.txt" target="_top">Another version of stringtok is given
- here</a>, suggested by Chris King and tweaked by Petr Prikryl,
- and this one uses the
- transformation functions mentioned below. If you are comfortable
- with reading the new function names, this version is recommended
- as an example.
- </p><p><span class="emphasis"><em>Added February 2001:</em></span> Mark Wilden pointed out that the
- standard <code class="code">std::getline()</code> function can be used with standard
- <a class="ulink" href="../27_io/howto.html" target="_top">istringstreams</a> to perform
- tokenizing as well. Build an istringstream from the input text,
- and then use std::getline with varying delimiters (the three-argument
- signature) to extract tokens into a string.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt05ch13s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt05ch13.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt05ch13s05.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Arbitrary Character Types </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Shrink to Fit</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s05.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s05.html
deleted file mode 100644
index 8b3596a30..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s05.html
+++ /dev/null
@@ -1,15 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Shrink to Fit</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /><link rel="prev" href="bk01pt05ch13s04.html" title="Tokenizing" /><link rel="next" href="bk01pt05ch13s06.html" title="CString (MFC)" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Shrink to Fit</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt05ch13s04.html">Prev</a> </td><th width="60%" align="center">Chapter 13. String Classes</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt05ch13s06.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="strings.string.shrink"></a>Shrink to Fit</h2></div></div></div><p>
- </p><p>From GCC 3.4 calling <code class="code">s.reserve(res)</code> on a
- <code class="code">string s</code> with <code class="code">res &lt; s.capacity()</code> will
- reduce the string's capacity to <code class="code">std::max(s.size(), res)</code>.
- </p><p>This behaviour is suggested, but not required by the standard. Prior
- to GCC 3.4 the following alternative can be used instead
- </p><pre class="programlisting">
- std::string(str.data(), str.size()).swap(str);
- </pre><p>This is similar to the idiom for reducing a <code class="code">vector</code>'s
- memory usage (see <a class="ulink" href="../faq/index.html#5_9" target="_top">FAQ 5.9</a>) but
- the regular copy constructor cannot be used because libstdc++'s
- <code class="code">string</code> is Copy-On-Write.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt05ch13s04.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt05ch13.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt05ch13s06.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Tokenizing </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> CString (MFC)</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s06.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s06.html
deleted file mode 100644
index 9e94ff4c1..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt05ch13s06.html
+++ /dev/null
@@ -1,94 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>CString (MFC)</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /><link rel="prev" href="bk01pt05ch13s05.html" title="Shrink to Fit" /><link rel="next" href="localization.html" title="Part VI.  Localization" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">CString (MFC)</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt05ch13s05.html">Prev</a> </td><th width="60%" align="center">Chapter 13. String Classes</th><td width="20%" align="right"> <a accesskey="n" href="localization.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="strings.string.Cstring"></a>CString (MFC)</h2></div></div></div><p>
- </p><p>A common lament seen in various newsgroups deals with the Standard
- string class as opposed to the Microsoft Foundation Class called
- CString. Often programmers realize that a standard portable
- answer is better than a proprietary nonportable one, but in porting
- their application from a Win32 platform, they discover that they
- are relying on special functions offered by the CString class.
- </p><p>Things are not as bad as they seem. In
- <a class="ulink" href="http://gcc.gnu.org/ml/gcc/1999-04n/msg00236.html" target="_top">this
- message</a>, Joe Buck points out a few very important things:
- </p><div class="itemizedlist"><ul type="disc"><li><p>The Standard <code class="code">string</code> supports all the operations
- that CString does, with three exceptions.
- </p></li><li><p>Two of those exceptions (whitespace trimming and case
- conversion) are trivial to implement. In fact, we do so
- on this page.
- </p></li><li><p>The third is <code class="code">CString::Format</code>, which allows formatting
- in the style of <code class="code">sprintf</code>. This deserves some mention:
- </p></li></ul></div><p>
- The old libg++ library had a function called form(), which did much
- the same thing. But for a Standard solution, you should use the
- stringstream classes. These are the bridge between the iostream
- hierarchy and the string class, and they operate with regular
- streams seamlessly because they inherit from the iostream
- hierarchy. An quick example:
- </p><pre class="programlisting">
- #include &lt;iostream&gt;
- #include &lt;string&gt;
- #include &lt;sstream&gt;
-
- string f (string&amp; incoming) // incoming is "foo N"
- {
- istringstream incoming_stream(incoming);
- string the_word;
- int the_number;
-
- incoming_stream &gt;&gt; the_word // extract "foo"
- &gt;&gt; the_number; // extract N
-
- ostringstream output_stream;
- output_stream &lt;&lt; "The word was " &lt;&lt; the_word
- &lt;&lt; " and 3*N was " &lt;&lt; (3*the_number);
-
- return output_stream.str();
- } </pre><p>A serious problem with CString is a design bug in its memory
- allocation. Specifically, quoting from that same message:
- </p><pre class="programlisting">
- CString suffers from a common programming error that results in
- poor performance. Consider the following code:
-
- CString n_copies_of (const CString&amp; foo, unsigned n)
- {
- CString tmp;
- for (unsigned i = 0; i &lt; n; i++)
- tmp += foo;
- return tmp;
- }
-
- This function is O(n^2), not O(n). The reason is that each +=
- causes a reallocation and copy of the existing string. Microsoft
- applications are full of this kind of thing (quadratic performance
- on tasks that can be done in linear time) -- on the other hand,
- we should be thankful, as it's created such a big market for high-end
- ix86 hardware. :-)
-
- If you replace CString with string in the above function, the
- performance is O(n).
- </pre><p>Joe Buck also pointed out some other things to keep in mind when
- comparing CString and the Standard string class:
- </p><div class="itemizedlist"><ul type="disc"><li><p>CString permits access to its internal representation; coders
- who exploited that may have problems moving to <code class="code">string</code>.
- </p></li><li><p>Microsoft ships the source to CString (in the files
- MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation
- bug and rebuild your MFC libraries.
- <span class="emphasis"><em><span class="emphasis"><em>Note:</em></span> It looks like the CString shipped
- with VC++6.0 has fixed this, although it may in fact have been
- one of the VC++ SPs that did it.</em></span>
- </p></li><li><p><code class="code">string</code> operations like this have O(n) complexity
- <span class="emphasis"><em>if the implementors do it correctly</em></span>. The libstdc++
- implementors did it correctly. Other vendors might not.
- </p></li><li><p>While parts of the SGI STL are used in libstdc++, their
- string class is not. The SGI <code class="code">string</code> is essentially
- <code class="code">vector&lt;char&gt;</code> and does not do any reference
- counting like libstdc++'s does. (It is O(n), though.)
- So if you're thinking about SGI's string or rope classes,
- you're now looking at four possibilities: CString, the
- libstdc++ string, the SGI string, and the SGI rope, and this
- is all before any allocator or traits customizations! (More
- choices than you can shake a stick at -- want fries with that?)
- </p></li></ul></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt05ch13s05.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt05ch13.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="localization.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Shrink to Fit </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part VI. 
- Localization
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt08ch19.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt08ch19.html
deleted file mode 100644
index 7f7f79025..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt08ch19.html
+++ /dev/null
@@ -1,36 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 19. Predefined</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="iterators.html" title="Part VIII.  Iterators" /><link rel="prev" href="iterators.html" title="Part VIII.  Iterators" /><link rel="next" href="bk01pt08ch19s02.html" title="One Past the End" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 19. Predefined</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="iterators.html">Prev</a> </td><th width="60%" align="center">Part VIII. 
- Iterators
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt08ch19s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.iterators.predefined"></a>Chapter 19. Predefined</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt08ch19.html#iterators.predefined.vs_pointers">Iterators vs. Pointers</a></span></dt><dt><span class="sect1"><a href="bk01pt08ch19s02.html">One Past the End</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="iterators.predefined.vs_pointers"></a>Iterators vs. Pointers</h2></div></div></div><p><a class="ulink" href="../faq/index.html#5_1" target="_top">FAQ 5.1</a> points out that iterators
- are not implemented as pointers. They are a generalization of
- pointers, but they are implemented in libstdc++ as separate classes.
- </p><p>Keeping that simple fact in mind as you design your code will
- prevent a whole lot of difficult-to-understand bugs.
- </p><p>You can think of it the other way 'round, even. Since iterators
- are a generalization, that means that <span class="emphasis"><em>pointers</em></span> are
- <span class="emphasis"><em>iterators</em></span>, and that pointers can be used whenever an
- iterator would be. All those functions in the Algorithms chapter
- of the Standard will work just as well on plain arrays and their
- pointers.
- </p><p>That doesn't mean that when you pass in a pointer, it gets wrapped
- into some special delegating iterator-to-pointer class with a layer
- of overhead. (If you think that's the case anywhere, you don't
- understand templates to begin with...) Oh, no; if you pass
- in a pointer, then the compiler will instantiate that template
- using T* as a type, and good old high-speed pointer arithmetic as
- its operations, so the resulting code will be doing exactly the same
- things as it would be doing if you had hand-coded it yourself (for
- the 273rd time).
- </p><p>How much overhead <span class="emphasis"><em>is</em></span> there when using an iterator class?
- Very little. Most of the layering classes contain nothing but
- typedefs, and typedefs are "meta-information" that simply
- tell the compiler some nicknames; they don't create code. That
- information gets passed down through inheritance, so while the
- compiler has to do work looking up all the names, your runtime code
- does not. (This has been a prime concern from the beginning.)
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="iterators.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="iterators.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt08ch19s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part VIII. 
- Iterators
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> One Past the End</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt08ch19s02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt08ch19s02.html
deleted file mode 100644
index ba36e2fd5..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt08ch19s02.html
+++ /dev/null
@@ -1,86 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>One Past the End</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk01pt08ch19.html" title="Chapter 19. Predefined" /><link rel="prev" href="bk01pt08ch19.html" title="Chapter 19. Predefined" /><link rel="next" href="algorithms.html" title="Part IX.  Algorithms" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">One Past the End</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt08ch19.html">Prev</a> </td><th width="60%" align="center">Chapter 19. Predefined</th><td width="20%" align="right"> <a accesskey="n" href="algorithms.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="iterators.predefined.end"></a>One Past the End</h2></div></div></div><p>This starts off sounding complicated, but is actually very easy,
- especially towards the end. Trust me.
- </p><p>Beginners usually have a little trouble understand the whole
- 'past-the-end' thing, until they remember their early algebra classes
- (see, they <span class="emphasis"><em>told</em></span> you that stuff would come in handy!) and
- the concept of half-open ranges.
- </p><p>First, some history, and a reminder of some of the funkier rules in
- C and C++ for builtin arrays. The following rules have always been
- true for both languages:
- </p><div class="orderedlist"><ol type="1"><li><p>You can point anywhere in the array, <span class="emphasis"><em>or to the first element
- past the end of the array</em></span>. A pointer that points to one
- past the end of the array is guaranteed to be as unique as a
- pointer to somewhere inside the array, so that you can compare
- such pointers safely.
- </p></li><li><p>You can only dereference a pointer that points into an array.
- If your array pointer points outside the array -- even to just
- one past the end -- and you dereference it, Bad Things happen.
- </p></li><li><p>Strictly speaking, simply pointing anywhere else invokes
- undefined behavior. Most programs won't puke until such a
- pointer is actually dereferenced, but the standards leave that
- up to the platform.
- </p></li></ol></div><p>The reason this past-the-end addressing was allowed is to make it
- easy to write a loop to go over an entire array, e.g.,
- while (*d++ = *s++);.
- </p><p>So, when you think of two pointers delimiting an array, don't think
- of them as indexing 0 through n-1. Think of them as <span class="emphasis"><em>boundary
- markers</em></span>:
- </p><pre class="programlisting">
-
- beginning end
- | |
- | | This is bad. Always having to
- | | remember to add or subtract one.
- | | Off-by-one bugs very common here.
- V V
- array of N elements
- |---|---|--...--|---|---|
- | 0 | 1 | ... |N-2|N-1|
- |---|---|--...--|---|---|
-
- ^ ^
- | |
- | | This is good. This is safe. This
- | | is guaranteed to work. Just don't
- | | dereference 'end'.
- beginning end
-
- </pre><p>See? Everything between the boundary markers is part of the array.
- Simple.
- </p><p>Now think back to your junior-high school algebra course, when you
- were learning how to draw graphs. Remember that a graph terminating
- with a solid dot meant, "Everything up through this point,"
- and a graph terminating with an open dot meant, "Everything up
- to, but not including, this point," respectively called closed
- and open ranges? Remember how closed ranges were written with
- brackets, <span class="emphasis"><em>[a,b]</em></span>, and open ranges were written with parentheses,
- <span class="emphasis"><em>(a,b)</em></span>?
- </p><p>The boundary markers for arrays describe a <span class="emphasis"><em>half-open range</em></span>,
- starting with (and including) the first element, and ending with (but
- not including) the last element: <span class="emphasis"><em>[beginning,end)</em></span>. See, I
- told you it would be simple in the end.
- </p><p>Iterators, and everything working with iterators, follows this same
- time-honored tradition. A container's <code class="code">begin()</code> method returns
- an iterator referring to the first element, and its <code class="code">end()</code>
- method returns a past-the-end iterator, which is guaranteed to be
- unique and comparable against any other iterator pointing into the
- middle of the container.
- </p><p>Container constructors, container methods, and algorithms, all take
- pairs of iterators describing a range of values on which to operate.
- All of these ranges are half-open ranges, so you pass the beginning
- iterator as the starting parameter, and the one-past-the-end iterator
- as the finishing parameter.
- </p><p>This generalizes very well. You can operate on sub-ranges quite
- easily this way; functions accepting a <span class="emphasis"><em>[first,last)</em></span> range
- don't know or care whether they are the boundaries of an entire {array,
- sequence, container, whatever}, or whether they only enclose a few
- elements from the center. This approach also makes zero-length
- sequences very simple to recognize: if the two endpoints compare
- equal, then the {array, sequence, container, whatever} is empty.
- </p><p>Just don't dereference <code class="code">end()</code>.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt08ch19.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk01pt08ch19.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="algorithms.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 19. Predefined </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part IX. 
- Algorithms
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt09ch20.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt09ch20.html
deleted file mode 100644
index 5ad9ee5ff..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt09ch20.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 20. Mutating</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; , &#10; algorithm&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="algorithms.html" title="Part IX.  Algorithms" /><link rel="prev" href="bk01pt09pr02.html" title="" /><link rel="next" href="numerics.html" title="Part X.  Numerics" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 20. Mutating</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt09pr02.html">Prev</a> </td><th width="60%" align="center">Part IX. 
- Algorithms
-
-</th><td width="20%" align="right"> <a accesskey="n" href="numerics.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.algorithms.mutating"></a>Chapter 20. Mutating</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="bk01pt09ch20.html#algorithms.mutating.swap">swap</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt09ch20.html#algorithms.swap.specializations">Specializations</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="algorithms.mutating.swap"></a><code class="function">swap</code></h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="algorithms.swap.specializations"></a>Specializations</h3></div></div></div><p>If you call <code class="code"> std::swap(x,y); </code> where x and y are standard
- containers, then the call will automatically be replaced by a call to
- <code class="code"> x.swap(y); </code> instead.
- </p><p>This allows member functions of each container class to take over, and
- containers' swap functions should have O(1) complexity according to
- the standard. (And while "should" allows implementations to
- behave otherwise and remain compliant, this implementation does in
- fact use constant-time swaps.) This should not be surprising, since
- for two containers of the same type to swap contents, only some
- internal pointers to storage need to be exchanged.
- </p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt09pr02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="algorithms.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="numerics.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part X. 
- Numerics
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt09pr02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt09pr02.html
deleted file mode 100644
index 8321586d2..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt09pr02.html
+++ /dev/null
@@ -1,41 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; , &#10; algorithm&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="algorithms.html" title="Part IX.  Algorithms" /><link rel="prev" href="algorithms.html" title="Part IX.  Algorithms" /><link rel="next" href="bk01pt09ch20.html" title="Chapter 20. Mutating" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="algorithms.html">Prev</a> </td><th width="60%" align="center">Part IX. 
- Algorithms
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt09ch20.html">Next</a></td></tr></table><hr /></div><div class="preface" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="id425058"></a></h2></div></div></div><p>
- The neatest accomplishment of the algorithms chapter is that all the
- work is done via iterators, not containers directly. This means two
- important things:
-</p><div class="orderedlist"><ol type="1"><li><p>
- Anything that behaves like an iterator can be used in one of
- these algorithms. Raw pointers make great candidates, thus
- built-in arrays are fine containers, as well as your own iterators.
- </p></li><li><p>
- The algorithms do not (and cannot) affect the container as a
- whole; only the things between the two iterator endpoints. If
- you pass a range of iterators only enclosing the middle third of
- a container, then anything outside that range is inviolate.
- </p></li></ol></div><p>
- Even strings can be fed through the algorithms here, although the
- string class has specialized versions of many of these functions
- (for example, <code class="code">string::find()</code>). Most of the examples
- on this page will use simple arrays of integers as a playground
- for algorithms, just to keep things simple. The use of
- <span class="emphasis"><em>N</em></span> as a size in the examples is to keep
- things easy to read but probably won't be valid code. You can
- use wrappers such as those described in the <a class="ulink" href="../23_containers/howto.html" target="_top">containers chapter</a> to
- keep real code readable.
- </p><p>
- The single thing that trips people up the most is the definition
- of <span class="emphasis"><em>range</em></span> used with iterators; the famous
- "past-the-end" rule that everybody loves to hate. The
- <a class="ulink" href="../24_iterators/howto.html#2" target="_top">iterators
- chapter</a> of this document has a complete explanation of
- this simple rule that seems to cause so much confusion. Once you
- get <span class="emphasis"><em>range</em></span> into your head (it's not that
- hard, honest!), then the algorithms are a cakewalk.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="algorithms.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="algorithms.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt09ch20.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part IX. 
- Algorithms
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 20. Mutating</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt10ch23s02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt10ch23s02.html
deleted file mode 100644
index 2d6695f67..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt10ch23s02.html
+++ /dev/null
@@ -1,19 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>C99</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="numerics_and_c.html" title="Chapter 23. Interacting with C" /><link rel="prev" href="numerics_and_c.html" title="Chapter 23. Interacting with C" /><link rel="next" href="io.html" title="Part XI.  Input and Output" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">C99</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="numerics_and_c.html">Prev</a> </td><th width="60%" align="center">Chapter 23. Interacting with C</th><td width="20%" align="right"> <a accesskey="n" href="io.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="numerics.c.c99"></a>C99</h2></div></div></div><p>In addition to the other topics on this page, we'll note here some
- of the C99 features that appear in libstdc++.
- </p><p>The C99 features depend on the <code class="code">--enable-c99</code> configure flag.
- This flag is already on by default, but it can be disabled by the
- user. Also, the configuration machinery will disable it if the
- necessary support for C99 (e.g., header files) cannot be found.
- </p><p>As of GCC 3.0, C99 support includes classification functions
- such as <code class="code">isnormal</code>, <code class="code">isgreater</code>,
- <code class="code">isnan</code>, etc.
- The functions used for 'long long' support such as <code class="code">strtoll</code>
- are supported, as is the <code class="code">lldiv_t</code> typedef. Also supported
- are the wide character functions using 'long long', like
- <code class="code">wcstoll</code>.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="numerics_and_c.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="numerics_and_c.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="io.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 23. Interacting with C </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part XI. 
- Input and Output
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch25s02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch25s02.html
deleted file mode 100644
index b804b5344..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch25s02.html
+++ /dev/null
@@ -1,77 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Buffering</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="streambufs.html" title="Chapter 25. Stream Buffers" /><link rel="prev" href="streambufs.html" title="Chapter 25. Stream Buffers" /><link rel="next" href="stringstreams.html" title="Chapter 26. Memory Based Streams" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Buffering</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="streambufs.html">Prev</a> </td><th width="60%" align="center">Chapter 25. Stream Buffers</th><td width="20%" align="right"> <a accesskey="n" href="stringstreams.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="io.streambuf.buffering"></a>Buffering</h2></div></div></div><p>First, are you sure that you understand buffering? Particularly
- the fact that C++ may not, in fact, have anything to do with it?
- </p><p>The rules for buffering can be a little odd, but they aren't any
- different from those of C. (Maybe that's why they can be a bit
- odd.) Many people think that writing a newline to an output
- stream automatically flushes the output buffer. This is true only
- when the output stream is, in fact, a terminal and not a file
- or some other device -- and <span class="emphasis"><em>that</em></span> may not even be true
- since C++ says nothing about files nor terminals. All of that is
- system-dependent. (The "newline-buffer-flushing only occurring
- on terminals" thing is mostly true on Unix systems, though.)
- </p><p>Some people also believe that sending <code class="code">endl</code> down an
- output stream only writes a newline. This is incorrect; after a
- newline is written, the buffer is also flushed. Perhaps this
- is the effect you want when writing to a screen -- get the text
- out as soon as possible, etc -- but the buffering is largely
- wasted when doing this to a file:
- </p><pre class="programlisting">
- output &lt;&lt; "a line of text" &lt;&lt; endl;
- output &lt;&lt; some_data_variable &lt;&lt; endl;
- output &lt;&lt; "another line of text" &lt;&lt; endl; </pre><p>The proper thing to do in this case to just write the data out
- and let the libraries and the system worry about the buffering.
- If you need a newline, just write a newline:
- </p><pre class="programlisting">
- output &lt;&lt; "a line of text\n"
- &lt;&lt; some_data_variable &lt;&lt; '\n'
- &lt;&lt; "another line of text\n"; </pre><p>I have also joined the output statements into a single statement.
- You could make the code prettier by moving the single newline to
- the start of the quoted text on the last line, for example.
- </p><p>If you do need to flush the buffer above, you can send an
- <code class="code">endl</code> if you also need a newline, or just flush the buffer
- yourself:
- </p><pre class="programlisting">
- output &lt;&lt; ...... &lt;&lt; flush; // can use std::flush manipulator
- output.flush(); // or call a member fn </pre><p>On the other hand, there are times when writing to a file should
- be like writing to standard error; no buffering should be done
- because the data needs to appear quickly (a prime example is a
- log file for security-related information). The way to do this is
- just to turn off the buffering <span class="emphasis"><em>before any I/O operations at
- all</em></span> have been done (note that opening counts as an I/O operation):
- </p><pre class="programlisting">
- std::ofstream os;
- std::ifstream is;
- int i;
-
- os.rdbuf()-&gt;pubsetbuf(0,0);
- is.rdbuf()-&gt;pubsetbuf(0,0);
-
- os.open("/foo/bar/baz");
- is.open("/qux/quux/quuux");
- ...
- os &lt;&lt; "this data is written immediately\n";
- is &gt;&gt; i; // and this will probably cause a disk read </pre><p>Since all aspects of buffering are handled by a streambuf-derived
- member, it is necessary to get at that member with <code class="code">rdbuf()</code>.
- Then the public version of <code class="code">setbuf</code> can be called. The
- arguments are the same as those for the Standard C I/O Library
- function (a buffer area followed by its size).
- </p><p>A great deal of this is implementation-dependent. For example,
- <code class="code">streambuf</code> does not specify any actions for its own
- <code class="code">setbuf()</code>-ish functions; the classes derived from
- <code class="code">streambuf</code> each define behavior that "makes
- sense" for that class: an argument of (0,0) turns off buffering
- for <code class="code">filebuf</code> but does nothing at all for its siblings
- <code class="code">stringbuf</code> and <code class="code">strstreambuf</code>, and specifying
- anything other than (0,0) has varying effects.
- User-defined classes derived from <code class="code">streambuf</code> can
- do whatever they want. (For <code class="code">filebuf</code> and arguments for
- <code class="code">(p,s)</code> other than zeros, libstdc++ does what you'd expect:
- the first <code class="code">s</code> bytes of <code class="code">p</code> are used as a buffer,
- which you must allocate and deallocate.)
- </p><p>A last reminder: there are usually more buffers involved than
- just those at the language/library level. Kernel buffers, disk
- buffers, and the like will also have an effect. Inspecting and
- changing those are system-dependent.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="streambufs.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="streambufs.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="stringstreams.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 25. Stream Buffers </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 26. Memory Based Streams</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch27s02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch27s02.html
deleted file mode 100644
index 2a2d7784a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch27s02.html
+++ /dev/null
@@ -1,95 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Binary Input and Output</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="fstreams.html" title="Chapter 27. File Based Streams" /><link rel="prev" href="fstreams.html" title="Chapter 27. File Based Streams" /><link rel="next" href="bk01pt11ch27s03.html" title="More Binary Input and Output" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Binary Input and Output</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="fstreams.html">Prev</a> </td><th width="60%" align="center">Chapter 27. File Based Streams</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt11ch27s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.io.filestreams.binary"></a>Binary Input and Output</h2></div></div></div><p>
- </p><p>The first and most important thing to remember about binary I/O is
- that opening a file with <code class="code">ios::binary</code> is not, repeat
- <span class="emphasis"><em>not</em></span>, the only thing you have to do. It is not a silver
- bullet, and will not allow you to use the <code class="code">&lt;&lt;/&gt;&gt;</code>
- operators of the normal fstreams to do binary I/O.
- </p><p>Sorry. Them's the breaks.
- </p><p>This isn't going to try and be a complete tutorial on reading and
- writing binary files (because "binary"
- <a class="ulink" href="#7" target="_top">covers a lot of ground)</a>, but we will try and clear
- up a couple of misconceptions and common errors.
- </p><p>First, <code class="code">ios::binary</code> has exactly one defined effect, no more
- and no less. Normal text mode has to be concerned with the newline
- characters, and the runtime system will translate between (for
- example) '\n' and the appropriate end-of-line sequence (LF on Unix,
- CRLF on DOS, CR on Macintosh, etc). (There are other things that
- normal mode does, but that's the most obvious.) Opening a file in
- binary mode disables this conversion, so reading a CRLF sequence
- under Windows won't accidentally get mapped to a '\n' character, etc.
- Binary mode is not supposed to suddenly give you a bitstream, and
- if it is doing so in your program then you've discovered a bug in
- your vendor's compiler (or some other part of the C++ implementation,
- possibly the runtime system).
- </p><p>Second, using <code class="code">&lt;&lt;</code> to write and <code class="code">&gt;&gt;</code> to
- read isn't going to work with the standard file stream classes, even
- if you use <code class="code">skipws</code> during reading. Why not? Because
- ifstream and ofstream exist for the purpose of <span class="emphasis"><em>formatting</em></span>,
- not reading and writing. Their job is to interpret the data into
- text characters, and that's exactly what you don't want to happen
- during binary I/O.
- </p><p>Third, using the <code class="code">get()</code> and <code class="code">put()/write()</code> member
- functions still aren't guaranteed to help you. These are
- "unformatted" I/O functions, but still character-based.
- (This may or may not be what you want, see below.)
- </p><p>Notice how all the problems here are due to the inappropriate use
- of <span class="emphasis"><em>formatting</em></span> functions and classes to perform something
- which <span class="emphasis"><em>requires</em></span> that formatting not be done? There are a
- seemingly infinite number of solutions, and a few are listed here:
- </p><div class="itemizedlist"><ul type="disc"><li><p>“<span class="quote">Derive your own fstream-type classes and write your own
- &lt;&lt;/&gt;&gt; operators to do binary I/O on whatever data
- types you're using.</span>”
- </p><p>
- This is a Bad Thing, because while
- the compiler would probably be just fine with it, other humans
- are going to be confused. The overloaded bitshift operators
- have a well-defined meaning (formatting), and this breaks it.
- </p></li><li><p>
- “<span class="quote">Build the file structure in memory, then
- <code class="code">mmap()</code> the file and copy the
- structure.
- </span>”
- </p><p>
- Well, this is easy to make work, and easy to break, and is
- pretty equivalent to using <code class="code">::read()</code> and
- <code class="code">::write()</code> directly, and makes no use of the
- iostream library at all...
- </p></li><li><p>
- “<span class="quote">Use streambufs, that's what they're there for.</span>”
- </p><p>
- While not trivial for the beginner, this is the best of all
- solutions. The streambuf/filebuf layer is the layer that is
- responsible for actual I/O. If you want to use the C++
- library for binary I/O, this is where you start.
- </p></li></ul></div><p>How to go about using streambufs is a bit beyond the scope of this
- document (at least for now), but while streambufs go a long way,
- they still leave a couple of things up to you, the programmer.
- As an example, byte ordering is completely between you and the
- operating system, and you have to handle it yourself.
- </p><p>Deriving a streambuf or filebuf
- class from the standard ones, one that is specific to your data
- types (or an abstraction thereof) is probably a good idea, and
- lots of examples exist in journals and on Usenet. Using the
- standard filebufs directly (either by declaring your own or by
- using the pointer returned from an fstream's <code class="code">rdbuf()</code>)
- is certainly feasible as well.
- </p><p>One area that causes problems is trying to do bit-by-bit operations
- with filebufs. C++ is no different from C in this respect: I/O
- must be done at the byte level. If you're trying to read or write
- a few bits at a time, you're going about it the wrong way. You
- must read/write an integral number of bytes and then process the
- bytes. (For example, the streambuf functions take and return
- variables of type <code class="code">int_type</code>.)
- </p><p>Another area of problems is opening text files in binary mode.
- Generally, binary mode is intended for binary files, and opening
- text files in binary mode means that you now have to deal with all of
- those end-of-line and end-of-file problems that we mentioned before.
- An instructive thread from comp.lang.c++.moderated delved off into
- this topic starting more or less at
- <a class="ulink" href="http://groups.google.com/groups?oi=djq&amp;selm=an_436187505" target="_top">this</a>
- article and continuing to the end of the thread. (You'll have to
- sort through some flames every couple of paragraphs, but the points
- made are good ones.)
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="fstreams.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="fstreams.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt11ch27s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 27. File Based Streams </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> More Binary Input and Output</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch27s03.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch27s03.html
deleted file mode 100644
index 6e51b647a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch27s03.html
+++ /dev/null
@@ -1,22 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>More Binary Input and Output</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="fstreams.html" title="Chapter 27. File Based Streams" /><link rel="prev" href="bk01pt11ch27s02.html" title="Binary Input and Output" /><link rel="next" href="io_and_c.html" title="Chapter 28. Interacting with C" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">More Binary Input and Output</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt11ch27s02.html">Prev</a> </td><th width="60%" align="center">Chapter 27. File Based Streams</th><td width="20%" align="right"> <a accesskey="n" href="io_and_c.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.io.filestreams.binary2"></a>More Binary Input and Output</h2></div></div></div><p>Towards the beginning of February 2001, the subject of
- "binary" I/O was brought up in a couple of places at the
- same time. One notable place was Usenet, where James Kanze and
- Dietmar Kühl separately posted articles on why attempting
- generic binary I/O was not a good idea. (Here are copies of
- <a class="ulink" href="binary_iostreams_kanze.txt" target="_top">Kanze's article</a> and
- <a class="ulink" href="binary_iostreams_kuehl.txt" target="_top">Kühl's article</a>.)
- </p><p>Briefly, the problems of byte ordering and type sizes mean that
- the unformatted functions like <code class="code">ostream::put()</code> and
- <code class="code">istream::get()</code> cannot safely be used to communicate
- between arbitrary programs, or across a network, or from one
- invocation of a program to another invocation of the same program
- on a different platform, etc.
- </p><p>The entire Usenet thread is instructive, and took place under the
- subject heading "binary iostreams" on both comp.std.c++
- and comp.lang.c++.moderated in parallel. Also in that thread,
- Dietmar Kühl mentioned that he had written a pair of stream
- classes that would read and write XDR, which is a good step towards
- a portable binary format.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt11ch27s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="fstreams.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="io_and_c.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Binary Input and Output </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 28. Interacting with C</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch28s02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch28s02.html
deleted file mode 100644
index 5e668931c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt11ch28s02.html
+++ /dev/null
@@ -1,49 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Performance</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="io_and_c.html" title="Chapter 28. Interacting with C" /><link rel="prev" href="io_and_c.html" title="Chapter 28. Interacting with C" /><link rel="next" href="extensions.html" title="Part XII.  Extensions" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Performance</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="io_and_c.html">Prev</a> </td><th width="60%" align="center">Chapter 28. Interacting with C</th><td width="20%" align="right"> <a accesskey="n" href="extensions.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.io.c.sync"></a>Performance</h2></div></div></div><p>
- Pathetic Performance? Ditch C.
- </p><p>It sounds like a flame on C, but it isn't. Really. Calm down.
- I'm just saying it to get your attention.
- </p><p>Because the C++ library includes the C library, both C-style and
- C++-style I/O have to work at the same time. For example:
- </p><pre class="programlisting">
- #include &lt;iostream&gt;
- #include &lt;cstdio&gt;
-
- std::cout &lt;&lt; "Hel";
- std::printf ("lo, worl");
- std::cout &lt;&lt; "d!\n";
- </pre><p>This must do what you think it does.
- </p><p>Alert members of the audience will immediately notice that buffering
- is going to make a hash of the output unless special steps are taken.
- </p><p>The special steps taken by libstdc++, at least for version 3.0,
- involve doing very little buffering for the standard streams, leaving
- most of the buffering to the underlying C library. (This kind of
- thing is tricky to get right.)
- The upside is that correctness is ensured. The downside is that
- writing through <code class="code">cout</code> can quite easily lead to awful
- performance when the C++ I/O library is layered on top of the C I/O
- library (as it is for 3.0 by default). Some patches have been applied
- which improve the situation for 3.1.
- </p><p>However, the C and C++ standard streams only need to be kept in sync
- when both libraries' facilities are in use. If your program only uses
- C++ I/O, then there's no need to sync with the C streams. The right
- thing to do in this case is to call
- </p><pre class="programlisting">
- #include <span class="emphasis"><em>any of the I/O headers such as ios, iostream, etc</em></span>
-
- std::ios::sync_with_stdio(false);
- </pre><p>You must do this before performing any I/O via the C++ stream objects.
- Once you call this, the C++ streams will operate independently of the
- (unused) C streams. For GCC 3.x, this means that <code class="code">cout</code> and
- company will become fully buffered on their own.
- </p><p>Note, by the way, that the synchronization requirement only applies to
- the standard streams (<code class="code">cin</code>, <code class="code">cout</code>,
- <code class="code">cerr</code>,
- <code class="code">clog</code>, and their wide-character counterparts). File stream
- objects that you declare yourself have no such requirement and are fully
- buffered.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="io_and_c.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="io_and_c.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="extensions.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 28. Interacting with C </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part XII. 
- Extensions
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch30s02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch30s02.html
deleted file mode 100644
index cb2031718..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch30s02.html
+++ /dev/null
@@ -1,55 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Semantics</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; debug&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="debug_mode.html" title="Chapter 30. Debug Mode" /><link rel="prev" href="debug_mode.html" title="Chapter 30. Debug Mode" /><link rel="next" href="bk01pt12ch30s03.html" title="Using" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Semantics</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="debug_mode.html">Prev</a> </td><th width="60%" align="center">Chapter 30. Debug Mode</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch30s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.debug_mode.semantics"></a>Semantics</h2></div></div></div><p>
- </p><p>A program that uses the C++ standard library correctly
- will maintain the same semantics under debug mode as it had with
- the normal (release) library. All functional and exception-handling
- guarantees made by the normal library also hold for the debug mode
- library, with one exception: performance guarantees made by the
- normal library may not hold in the debug mode library. For
- instance, erasing an element in a <code class="code">std::list</code> is a
- constant-time operation in normal library, but in debug mode it is
- linear in the number of iterators that reference that particular
- list. So while your (correct) program won't change its results, it
- is likely to execute more slowly.</p><p>libstdc++ includes many extensions to the C++ standard library. In
- some cases the extensions are obvious, such as the hashed
- associative containers, whereas other extensions give predictable
- results to behavior that would otherwise be undefined, such as
- throwing an exception when a <code class="code">std::basic_string</code> is
- constructed from a NULL character pointer. This latter category also
- includes implementation-defined and unspecified semantics, such as
- the growth rate of a vector. Use of these extensions is not
- considered incorrect, so code that relies on them will not be
- rejected by debug mode. However, use of these extensions may affect
- the portability of code to other implementations of the C++ standard
- library, and is therefore somewhat hazardous. For this reason, the
- libstdc++ debug mode offers a "pedantic" mode (similar to
- GCC's <code class="code">-pedantic</code> compiler flag) that attempts to emulate
- the semantics guaranteed by the C++ standard. For
- instance, constructing a <code class="code">std::basic_string</code> with a NULL
- character pointer would result in an exception under normal mode or
- non-pedantic debug mode (this is a libstdc++ extension), whereas
- under pedantic debug mode libstdc++ would signal an error. To enable
- the pedantic debug mode, compile your program with
- both <code class="code">-D_GLIBCXX_DEBUG</code>
- and <code class="code">-D_GLIBCXX_DEBUG_PEDANTIC</code> .
- (N.B. In GCC 3.4.x and 4.0.0, due to a bug,
- <code class="code">-D_GLIBXX_DEBUG_PEDANTIC</code> was also needed. The problem has
- been fixed in GCC 4.0.1 and later versions.) </p><p>The following library components provide extra debugging
- capabilities in debug mode:</p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">std::basic_string</code> (no safe iterators and see note below)</p></li><li><p><code class="code">std::bitset</code></p></li><li><p><code class="code">std::deque</code></p></li><li><p><code class="code">std::list</code></p></li><li><p><code class="code">std::map</code></p></li><li><p><code class="code">std::multimap</code></p></li><li><p><code class="code">std::multiset</code></p></li><li><p><code class="code">std::set</code></p></li><li><p><code class="code">std::vector</code></p></li><li><p><code class="code">std::unordered_map</code></p></li><li><p><code class="code">std::unordered_multimap</code></p></li><li><p><code class="code">std::unordered_set</code></p></li><li><p><code class="code">std::unordered_multiset</code></p></li></ul></div><p>N.B. although there are precondition checks for some string operations,
-e.g. <code class="code">operator[]</code>,
-they will not always be run when using the <code class="code">char</code> and
-<code class="code">wchar_t</code> specialisations (<code class="code">std::string</code> and
-<code class="code">std::wstring</code>). This is because libstdc++ uses GCC's
-<code class="code">extern template</code> extension to provide explicit instantiations
-of <code class="code">std::string</code> and <code class="code">std::wstring</code>, and those
-explicit instantiations don't include the debug-mode checks. If the
-containing functions are inlined then the checks will run, so compiling
-with <code class="code">-O1</code> might be enough to enable them. Alternatively
-<code class="code">-D_GLIBCXX_EXTERN_TEMPLATE=0</code> will suppress the declarations
-of the explicit instantiations and cause the functions to be instantiated
-with the debug-mode checks included, but this is unsupported and not
-guaranteed to work. For full debug-mode support you can use the
-<code class="code">__gnu_debug::basic_string</code> debugging container directly,
-which always works correctly.
-</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="debug_mode.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="debug_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch30s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 30. Debug Mode </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Using</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch30s03.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch30s03.html
deleted file mode 100644
index 65af5d5cd..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch30s03.html
+++ /dev/null
@@ -1,24 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Using</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; debug&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="debug_mode.html" title="Chapter 30. Debug Mode" /><link rel="prev" href="bk01pt12ch30s02.html" title="Semantics" /><link rel="next" href="bk01pt12ch30s04.html" title="Design" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Using</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch30s02.html">Prev</a> </td><th width="60%" align="center">Chapter 30. Debug Mode</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch30s04.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.debug_mode.using"></a>Using</h2></div></div></div><p>
- </p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="debug_mode.using.mode"></a>Using the Debug Mode</h3></div></div></div><p>To use the libstdc++ debug mode, compile your application with the
- compiler flag <code class="code">-D_GLIBCXX_DEBUG</code>. Note that this flag
- changes the sizes and behavior of standard class templates such
- as <code class="code">std::vector</code>, and therefore you can only link code
- compiled with debug mode and code compiled without debug mode if no
- instantiation of a container is passed between the two translation
- units.</p><p>By default, error messages are formatted to fit on lines of about
- 78 characters. The environment variable
- <code class="code">GLIBCXX_DEBUG_MESSAGE_LENGTH</code> can be used to request a
- different length.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="debug_mode.using.specific"></a>Using a Specific Debug Container</h3></div></div></div><p>When it is not feasible to recompile your entire application, or
- only specific containers need checking, debugging containers are
- available as GNU extensions. These debugging containers are
- functionally equivalent to the standard drop-in containers used in
- debug mode, but they are available in a separate namespace as GNU
- extensions and may be used in programs compiled with either release
- mode or with debug mode. The
- following table provides the names and headers of the debugging
- containers:
-</p><div class="table"><a id="id455307"></a><p class="title"><b>Table 30.1. Debugging Containers</b></p><div class="table-contents"><table summary="Debugging Containers" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col /><col /></colgroup><thead><tr><th align="left">Container</th><th align="left">Header</th><th align="left">Debug container</th><th align="left">Debug header</th><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></thead><tbody><tr><td align="left"><code class="classname">std::bitset</code></td><td align="left"><code class="filename">bitset</code></td><td align="left"><code class="classname">__gnu_debug::bitset</code></td><td align="left"><code class="filename">bitset</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::deque</code></td><td align="left"><code class="filename">deque</code></td><td align="left"><code class="classname">__gnu_debug::deque</code></td><td align="left"><code class="filename">deque</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::list</code></td><td align="left"><code class="filename">list</code></td><td align="left"><code class="classname">__gnu_debug::list</code></td><td align="left"><code class="filename">list</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::map</code></td><td align="left"><code class="filename">map</code></td><td align="left"><code class="classname">__gnu_debug::map</code></td><td align="left"><code class="filename">map</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::multimap</code></td><td align="left"><code class="filename">map</code></td><td align="left"><code class="classname">__gnu_debug::multimap</code></td><td align="left"><code class="filename">map</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::multiset</code></td><td align="left"><code class="filename">set</code></td><td align="left"><code class="classname">__gnu_debug::multiset</code></td><td align="left"><code class="filename">set</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::set</code></td><td align="left"><code class="filename">set</code></td><td align="left"><code class="classname">__gnu_debug::set</code></td><td align="left"><code class="filename">set</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::string</code></td><td align="left"><code class="filename">string</code></td><td align="left"><code class="classname">__gnu_debug::string</code></td><td align="left"><code class="filename">string</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::wstring</code></td><td align="left"><code class="filename">string</code></td><td align="left"><code class="classname">__gnu_debug::wstring</code></td><td align="left"><code class="filename">string</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::basic_string</code></td><td align="left"><code class="filename">string</code></td><td align="left"><code class="classname">__gnu_debug::basic_string</code></td><td align="left"><code class="filename">string</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::vector</code></td><td align="left"><code class="filename">vector</code></td><td align="left"><code class="classname">__gnu_debug::vector</code></td><td align="left"><code class="filename">vector</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p>In addition, when compiling in C++0x mode, these additional
-containers have additional debug capability.
-</p><div class="table"><a id="id393058"></a><p class="title"><b>Table 30.2. Debugging Containers C++0x</b></p><div class="table-contents"><table summary="Debugging Containers C++0x" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col /><col /></colgroup><thead><tr><th align="left">Container</th><th align="left">Header</th><th align="left">Debug container</th><th align="left">Debug header</th><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></thead><tbody><tr><td align="left"><code class="classname">std::unordered_map</code></td><td align="left"><code class="filename">unordered_map</code></td><td align="left"><code class="classname">__gnu_debug::unordered_map</code></td><td align="left"><code class="filename">unordered_map</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::unordered_multimap</code></td><td align="left"><code class="filename">unordered_map</code></td><td align="left"><code class="classname">__gnu_debug::unordered_multimap</code></td><td align="left"><code class="filename">unordered_map</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::unordered_set</code></td><td align="left"><code class="filename">unordered_set</code></td><td align="left"><code class="classname">__gnu_debug::unordered_set</code></td><td align="left"><code class="filename">unordered_set</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr><tr><td align="left"><code class="classname">std::unordered_multiset</code></td><td align="left"><code class="filename">unordered_set</code></td><td align="left"><code class="classname">__gnu_debug::unordered_multiset</code></td><td align="left"><code class="filename">unordered_set</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch30s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="debug_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch30s04.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Semantics </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Design</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch30s04.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch30s04.html
deleted file mode 100644
index b76fc3dc6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch30s04.html
+++ /dev/null
@@ -1,409 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Design</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; debug&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="debug_mode.html" title="Chapter 30. Debug Mode" /><link rel="prev" href="bk01pt12ch30s03.html" title="Using" /><link rel="next" href="parallel_mode.html" title="Chapter 31. Parallel Mode" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Design</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch30s03.html">Prev</a> </td><th width="60%" align="center">Chapter 30. Debug Mode</th><td width="20%" align="right"> <a accesskey="n" href="parallel_mode.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.debug_mode.design"></a>Design</h2></div></div></div><p>
- </p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.debug_mode.design.goals"></a>Goals</h3></div></div></div><p>
- </p><p> The libstdc++ debug mode replaces unsafe (but efficient) standard
- containers and iterators with semantically equivalent safe standard
- containers and iterators to aid in debugging user programs. The
- following goals directed the design of the libstdc++ debug mode:</p><div class="itemizedlist"><ul type="disc"><li><p><span class="emphasis"><em>Correctness</em></span>: the libstdc++ debug mode must not change
- the semantics of the standard library for all cases specified in
- the ANSI/ISO C++ standard. The essence of this constraint is that
- any valid C++ program should behave in the same manner regardless
- of whether it is compiled with debug mode or release mode. In
- particular, entities that are defined in namespace std in release
- mode should remain defined in namespace std in debug mode, so that
- legal specializations of namespace std entities will remain
- valid. A program that is not valid C++ (e.g., invokes undefined
- behavior) is not required to behave similarly, although the debug
- mode will abort with a diagnostic when it detects undefined
- behavior.</p></li><li><p><span class="emphasis"><em>Performance</em></span>: the additional of the libstdc++ debug mode
- must not affect the performance of the library when it is compiled
- in release mode. Performance of the libstdc++ debug mode is
- secondary (and, in fact, will be worse than the release
- mode).</p></li><li><p><span class="emphasis"><em>Usability</em></span>: the libstdc++ debug mode should be easy to
- use. It should be easily incorporated into the user's development
- environment (e.g., by requiring only a single new compiler switch)
- and should produce reasonable diagnostics when it detects a
- problem with the user program. Usability also involves detection
- of errors when using the debug mode incorrectly, e.g., by linking
- a release-compiled object against a debug-compiled object if in
- fact the resulting program will not run correctly.</p></li><li><p><span class="emphasis"><em>Minimize recompilation</em></span>: While it is expected that
- users recompile at least part of their program to use debug
- mode, the amount of recompilation affects the
- detect-compile-debug turnaround time. This indirectly affects the
- usefulness of the debug mode, because debugging some applications
- may require rebuilding a large amount of code, which may not be
- feasible when the suspect code may be very localized. There are
- several levels of conformance to this requirement, each with its
- own usability and implementation characteristics. In general, the
- higher-numbered conformance levels are more usable (i.e., require
- less recompilation) but are more complicated to implement than
- the lower-numbered conformance levels.
- </p><div class="orderedlist"><ol type="1"><li><p><span class="emphasis"><em>Full recompilation</em></span>: The user must recompile his or
- her entire application and all C++ libraries it depends on,
- including the C++ standard library that ships with the
- compiler. This must be done even if only a small part of the
- program can use debugging features.</p></li><li><p><span class="emphasis"><em>Full user recompilation</em></span>: The user must recompile
- his or her entire application and all C++ libraries it depends
- on, but not the C++ standard library itself. This must be done
- even if only a small part of the program can use debugging
- features. This can be achieved given a full recompilation
- system by compiling two versions of the standard library when
- the compiler is installed and linking against the appropriate
- one, e.g., a multilibs approach.</p></li><li><p><span class="emphasis"><em>Partial recompilation</em></span>: The user must recompile the
- parts of his or her application and the C++ libraries it
- depends on that will use the debugging facilities
- directly. This means that any code that uses the debuggable
- standard containers would need to be recompiled, but code
- that does not use them (but may, for instance, use IOStreams)
- would not have to be recompiled.</p></li><li><p><span class="emphasis"><em>Per-use recompilation</em></span>: The user must recompile the
- parts of his or her application and the C++ libraries it
- depends on where debugging should occur, and any other code
- that interacts with those containers. This means that a set of
- translation units that accesses a particular standard
- container instance may either be compiled in release mode (no
- checking) or debug mode (full checking), but must all be
- compiled in the same way; a translation unit that does not see
- that standard container instance need not be recompiled. This
- also means that a translation unit <span class="emphasis"><em>A</em></span> that contains a
- particular instantiation
- (say, <code class="code">std::vector&lt;int&gt;</code>) compiled in release
- mode can be linked against a translation unit <span class="emphasis"><em>B</em></span> that
- contains the same instantiation compiled in debug mode (a
- feature not present with partial recompilation). While this
- behavior is technically a violation of the One Definition
- Rule, this ability tends to be very important in
- practice. The libstdc++ debug mode supports this level of
- recompilation. </p></li><li><p><span class="emphasis"><em>Per-unit recompilation</em></span>: The user must only
- recompile the translation units where checking should occur,
- regardless of where debuggable standard containers are
- used. This has also been dubbed "<code class="code">-g</code> mode",
- because the <code class="code">-g</code> compiler switch works in this way,
- emitting debugging information at a per--translation-unit
- granularity. We believe that this level of recompilation is in
- fact not possible if we intend to supply safe iterators, leave
- the program semantics unchanged, and not regress in
- performance under release mode because we cannot associate
- extra information with an iterator (to form a safe iterator)
- without either reserving that space in release mode
- (performance regression) or allocating extra memory associated
- with each iterator with <code class="code">new</code> (changes the program
- semantics).</p></li></ol></div><p>
- </p></li></ul></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.debug_mode.design.methods"></a>Methods</h3></div></div></div><p>
- </p><p>This section provides an overall view of the design of the
- libstdc++ debug mode and details the relationship between design
- decisions and the stated design goals.</p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="debug_mode.design.methods.wrappers"></a>The Wrapper Model</h4></div></div></div><p>The libstdc++ debug mode uses a wrapper model where the debugging
- versions of library components (e.g., iterators and containers) form
- a layer on top of the release versions of the library
- components. The debugging components first verify that the operation
- is correct (aborting with a diagnostic if an error is found) and
- will then forward to the underlying release-mode container that will
- perform the actual work. This design decision ensures that we cannot
- regress release-mode performance (because the release-mode
- containers are left untouched) and partially enables <a class="ulink" href="#mixing" target="_top">mixing debug and release code</a> at link time,
- although that will not be discussed at this time.</p><p>Two types of wrappers are used in the implementation of the debug
- mode: container wrappers and iterator wrappers. The two types of
- wrappers interact to maintain relationships between iterators and
- their associated containers, which are necessary to detect certain
- types of standard library usage errors such as dereferencing
- past-the-end iterators or inserting into a container using an
- iterator from a different container.</p><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="debug_mode.design.methods.safe_iter"></a>Safe Iterators</h5></div></div></div><p>Iterator wrappers provide a debugging layer over any iterator that
- is attached to a particular container, and will manage the
- information detailing the iterator's state (singular,
- dereferenceable, etc.) and tracking the container to which the
- iterator is attached. Because iterators have a well-defined, common
- interface the iterator wrapper is implemented with the iterator
- adaptor class template <code class="code">__gnu_debug::_Safe_iterator</code>,
- which takes two template parameters:</p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">Iterator</code>: The underlying iterator type, which must
- be either the <code class="code">iterator</code> or <code class="code">const_iterator</code>
- typedef from the sequence type this iterator can reference.</p></li><li><p><code class="code">Sequence</code>: The type of sequence that this iterator
- references. This sequence must be a safe sequence (discussed below)
- whose <code class="code">iterator</code> or <code class="code">const_iterator</code> typedef
- is the type of the safe iterator.</p></li></ul></div></div><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="debug_mode.design.methods.safe_seq"></a>Safe Sequences (Containers)</h5></div></div></div><p>Container wrappers provide a debugging layer over a particular
- container type. Because containers vary greatly in the member
- functions they support and the semantics of those member functions
- (especially in the area of iterator invalidation), container
- wrappers are tailored to the container they reference, e.g., the
- debugging version of <code class="code">std::list</code> duplicates the entire
- interface of <code class="code">std::list</code>, adding additional semantic
- checks and then forwarding operations to the
- real <code class="code">std::list</code> (a public base class of the debugging
- version) as appropriate. However, all safe containers inherit from
- the class template <code class="code">__gnu_debug::_Safe_sequence</code>,
- instantiated with the type of the safe container itself (an instance
- of the curiously recurring template pattern).</p><p>The iterators of a container wrapper will be
- <a class="ulink" href="#safe_iterator" target="_top">safe iterators</a> that reference sequences
- of this type and wrap the iterators provided by the release-mode
- base class. The debugging container will use only the safe
- iterators within its own interface (therefore requiring the user to
- use safe iterators, although this does not change correct user
- code) and will communicate with the release-mode base class with
- only the underlying, unsafe, release-mode iterators that the base
- class exports.</p><p> The debugging version of <code class="code">std::list</code> will have the
- following basic structure:</p><pre class="programlisting">
-template&lt;typename _Tp, typename _Allocator = allocator&lt;_Tp&gt;
- class debug-list :
- public release-list&lt;_Tp, _Allocator&gt;,
- public __gnu_debug::_Safe_sequence&lt;debug-list&lt;_Tp, _Allocator&gt; &gt;
- {
- typedef release-list&lt;_Tp, _Allocator&gt; _Base;
- typedef debug-list&lt;_Tp, _Allocator&gt; _Self;
-
- public:
- typedef __gnu_debug::_Safe_iterator&lt;typename _Base::iterator, _Self&gt; iterator;
- typedef __gnu_debug::_Safe_iterator&lt;typename _Base::const_iterator, _Self&gt; const_iterator;
-
- // duplicate std::list interface with debugging semantics
- };
-</pre></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="debug_mode.design.methods.precond"></a>Precondition Checking</h4></div></div></div><p>The debug mode operates primarily by checking the preconditions of
- all standard library operations that it supports. Preconditions that
- are always checked (regardless of whether or not we are in debug
- mode) are checked via the <code class="code">__check_xxx</code> macros defined
- and documented in the source
- file <code class="code">include/debug/debug.h</code>. Preconditions that may or
- may not be checked, depending on the debug-mode
- macro <code class="code">_GLIBCXX_DEBUG</code>, are checked via
- the <code class="code">__requires_xxx</code> macros defined and documented in the
- same source file. Preconditions are validated using any additional
- information available at run-time, e.g., the containers that are
- associated with a particular iterator, the position of the iterator
- within those containers, the distance between two iterators that may
- form a valid range, etc. In the absence of suitable information,
- e.g., an input iterator that is not a safe iterator, these
- precondition checks will silently succeed.</p><p>The majority of precondition checks use the aforementioned macros,
- which have the secondary benefit of having prewritten debug
- messages that use information about the current status of the
- objects involved (e.g., whether an iterator is singular or what
- sequence it is attached to) along with some static information
- (e.g., the names of the function parameters corresponding to the
- objects involved). When not using these macros, the debug mode uses
- either the debug-mode assertion
- macro <code class="code">_GLIBCXX_DEBUG_ASSERT</code> , its pedantic
- cousin <code class="code">_GLIBCXX_DEBUG_PEDASSERT</code>, or the assertion
- check macro that supports more advance formulation of error
- messages, <code class="code">_GLIBCXX_DEBUG_VERIFY</code>. These macros are
- documented more thoroughly in the debug mode source code.</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="debug_mode.design.methods.coexistence"></a>Release- and debug-mode coexistence</h4></div></div></div><p>The libstdc++ debug mode is the first debug mode we know of that
- is able to provide the "Per-use recompilation" (4) guarantee, that
- allows release-compiled and debug-compiled code to be linked and
- executed together without causing unpredictable behavior. This
- guarantee minimizes the recompilation that users are required to
- perform, shortening the detect-compile-debug bug hunting cycle
- and making the debug mode easier to incorporate into development
- environments by minimizing dependencies.</p><p>Achieving link- and run-time coexistence is not a trivial
- implementation task. To achieve this goal we required a small
- extension to the GNU C++ compiler (described in the GCC Manual for
- C++ Extensions, see <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Strong-Using.html" target="_top">strong
- using</a>), and a complex organization of debug- and
- release-modes. The end result is that we have achieved per-use
- recompilation but have had to give up some checking of the
- <code class="code">std::basic_string</code> class template (namely, safe
- iterators).
-</p><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="methods.coexistence.compile"></a>Compile-time coexistence of release- and debug-mode components</h5></div></div></div><p>Both the release-mode components and the debug-mode
- components need to exist within a single translation unit so that
- the debug versions can wrap the release versions. However, only one
- of these components should be user-visible at any particular
- time with the standard name, e.g., <code class="code">std::list</code>. </p><p>In release mode, we define only the release-mode version of the
- component with its standard name and do not include the debugging
- component at all. The release mode version is defined within the
- namespace <code class="code">std</code>. Minus the namespace associations, this
- method leaves the behavior of release mode completely unchanged from
- its behavior prior to the introduction of the libstdc++ debug
- mode. Here's an example of what this ends up looking like, in
- C++.</p><pre class="programlisting">
-namespace std
-{
- template&lt;typename _Tp, typename _Alloc = allocator&lt;_Tp&gt; &gt;
- class list
- {
- // ...
- };
-} // namespace std
-</pre><p>In debug mode we include the release-mode container (which is now
-defined in in the namespace <code class="code">__norm</code>) and also the
-debug-mode container. The debug-mode container is defined within the
-namespace <code class="code">__debug</code>, which is associated with namespace
-<code class="code">std</code> via the GNU namespace association extension. This
-method allows the debug and release versions of the same component to
-coexist at compile-time and link-time without causing an unreasonable
-maintenance burden, while minimizing confusion. Again, this boils down
-to C++ code as follows:</p><pre class="programlisting">
-namespace std
-{
- namespace __norm
- {
- template&lt;typename _Tp, typename _Alloc = allocator&lt;_Tp&gt; &gt;
- class list
- {
- // ...
- };
- } // namespace __gnu_norm
-
- namespace __debug
- {
- template&lt;typename _Tp, typename _Alloc = allocator&lt;_Tp&gt; &gt;
- class list
- : public __norm::list&lt;_Tp, _Alloc&gt;,
- public __gnu_debug::_Safe_sequence&lt;list&lt;_Tp, _Alloc&gt; &gt;
- {
- // ...
- };
- } // namespace __norm
-
- using namespace __debug __attribute__ ((strong));
-}
-</pre></div><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="methods.coexistence.link"></a>Link- and run-time coexistence of release- and
- debug-mode components</h5></div></div></div><p>Because each component has a distinct and separate release and
-debug implementation, there are are no issues with link-time
-coexistence: the separate namespaces result in different mangled
-names, and thus unique linkage.</p><p>However, components that are defined and used within the C++
-standard library itself face additional constraints. For instance,
-some of the member functions of <code class="code"> std::moneypunct</code> return
-<code class="code">std::basic_string</code>. Normally, this is not a problem, but
-with a mixed mode standard library that could be using either
-debug-mode or release-mode <code class="code"> basic_string</code> objects, things
-get more complicated. As the return value of a function is not
-encoded into the mangled name, there is no way to specify a
-release-mode or a debug-mode string. In practice, this results in
-runtime errors. A simplified example of this problem is as follows.
-</p><p> Take this translation unit, compiled in debug-mode: </p><pre class="programlisting">
-// -D_GLIBCXX_DEBUG
-#include &lt;string&gt;
-
-std::string test02();
-
-std::string test01()
-{
- return test02();
-}
-
-int main()
-{
- test01();
- return 0;
-}
-</pre><p> ... and linked to this translation unit, compiled in release mode:</p><pre class="programlisting">
-#include &lt;string&gt;
-
-std::string
-test02()
-{
- return std::string("toast");
-}
-</pre><p> For this reason we cannot easily provide safe iterators for
- the <code class="code">std::basic_string</code> class template, as it is present
- throughout the C++ standard library. For instance, locale facets
- define typedefs that include <code class="code">basic_string</code>: in a mixed
- debug/release program, should that typedef be based on the
- debug-mode <code class="code">basic_string</code> or the
- release-mode <code class="code">basic_string</code>? While the answer could be
- "both", and the difference hidden via renaming a la the
- debug/release containers, we must note two things about locale
- facets:</p><div class="orderedlist"><ol type="1"><li><p>They exist as shared state: one can create a facet in one
- translation unit and access the facet via the same type name in a
- different translation unit. This means that we cannot have two
- different versions of locale facets, because the types would not be
- the same across debug/release-mode translation unit barriers.</p></li><li><p>They have virtual functions returning strings: these functions
- mangle in the same way regardless of the mangling of their return
- types (see above), and their precise signatures can be relied upon
- by users because they may be overridden in derived classes.</p></li></ol></div><p>With the design of libstdc++ debug mode, we cannot effectively hide
- the differences between debug and release-mode strings from the
- user. Failure to hide the differences may result in unpredictable
- behavior, and for this reason we have opted to only
- perform <code class="code">basic_string</code> changes that do not require ABI
- changes. The effect on users is expected to be minimal, as there are
- simple alternatives (e.g., <code class="code">__gnu_debug::basic_string</code>),
- and the usability benefit we gain from the ability to mix debug- and
- release-compiled translation units is enormous.</p></div><div class="sect4" lang="en" xml:lang="en"><div class="titlepage"><div><div><h5 class="title"><a id="methods.coexistence.alt"></a>Alternatives for Coexistence</h5></div></div></div><p>The coexistence scheme above was chosen over many alternatives,
- including language-only solutions and solutions that also required
- extensions to the C++ front end. The following is a partial list of
- solutions, with justifications for our rejection of each.</p><div class="itemizedlist"><ul type="disc"><li><p><span class="emphasis"><em>Completely separate debug/release libraries</em></span>: This is by
- far the simplest implementation option, where we do not allow any
- coexistence of debug- and release-compiled translation units in a
- program. This solution has an extreme negative affect on usability,
- because it is quite likely that some libraries an application
- depends on cannot be recompiled easily. This would not meet
- our <span class="emphasis"><em>usability</em></span> or <span class="emphasis"><em>minimize recompilation</em></span> criteria
- well.</p></li><li><p><span class="emphasis"><em>Add a <code class="code">Debug</code> boolean template parameter</em></span>:
- Partial specialization could be used to select the debug
- implementation when <code class="code">Debug == true</code>, and the state
- of <code class="code">_GLIBCXX_DEBUG</code> could decide whether the
- default <code class="code">Debug</code> argument is <code class="code">true</code>
- or <code class="code">false</code>. This option would break conformance with the
- C++ standard in both debug <span class="emphasis"><em>and</em></span> release modes. This would
- not meet our <span class="emphasis"><em>correctness</em></span> criteria. </p></li><li><p><span class="emphasis"><em>Packaging a debug flag in the allocators</em></span>: We could
- reuse the <code class="code">Allocator</code> template parameter of containers
- by adding a sentinel wrapper <code class="code">debug&lt;&gt;</code> that
- signals the user's intention to use debugging, and pick up
- the <code class="code">debug&lt;&gt;</code> allocator wrapper in a partial
- specialization. However, this has two drawbacks: first, there is a
- conformance issue because the default allocator would not be the
- standard-specified <code class="code">std::allocator&lt;T&gt;</code>. Secondly
- (and more importantly), users that specify allocators instead of
- implicitly using the default allocator would not get debugging
- containers. Thus this solution fails the <span class="emphasis"><em>correctness</em></span>
- criteria.</p></li><li><p><span class="emphasis"><em>Define debug containers in another namespace, and employ
- a <code class="code">using</code> declaration (or directive)</em></span>: This is an
- enticing option, because it would eliminate the need for
- the <code class="code">link_name</code> extension by aliasing the
- templates. However, there is no true template aliasing mechanism
- is C++, because both <code class="code">using</code> directives and using
- declarations disallow specialization. This method fails
- the <span class="emphasis"><em>correctness</em></span> criteria.</p></li><li><p><span class="emphasis"><em> Use implementation-specific properties of anonymous
- namespaces. </em></span>
- See <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2003-08/msg00004.html" target="_top"> this post
- </a>
- This method fails the <span class="emphasis"><em>correctness</em></span> criteria.</p></li><li><p><span class="emphasis"><em>Extension: allow reopening on namespaces</em></span>: This would
- allow the debug mode to effectively alias the
- namespace <code class="code">std</code> to an internal namespace, such
- as <code class="code">__gnu_std_debug</code>, so that it is completely
- separate from the release-mode <code class="code">std</code> namespace. While
- this will solve some renaming problems and ensure that
- debug- and release-compiled code cannot be mixed unsafely, it ensures that
- debug- and release-compiled code cannot be mixed at all. For
- instance, the program would have two <code class="code">std::cout</code>
- objects! This solution would fails the <span class="emphasis"><em>minimize
- recompilation</em></span> requirement, because we would only be able to
- support option (1) or (2).</p></li><li><p><span class="emphasis"><em>Extension: use link name</em></span>: This option involves
- complicated re-naming between debug-mode and release-mode
- components at compile time, and then a g++ extension called <span class="emphasis"><em>
- link name </em></span> to recover the original names at link time. There
- are two drawbacks to this approach. One, it's very verbose,
- relying on macro renaming at compile time and several levels of
- include ordering. Two, ODR issues remained with container member
- functions taking no arguments in mixed-mode settings resulting in
- equivalent link names, <code class="code"> vector::push_back() </code> being
- one example.
- See <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2003-08/msg00177.html" target="_top">link
- name</a> </p></li></ul></div><p>Other options may exist for implementing the debug mode, many of
- which have probably been considered and others that may still be
- lurking. This list may be expanded over time to include other
- options that we could have implemented, but in all cases the full
- ramifications of the approach (as measured against the design goals
- for a libstdc++ debug mode) should be considered first. The DejaGNU
- testsuite includes some testcases that check for known problems with
- some solutions (e.g., the <code class="code">using</code> declaration solution
- that breaks user specialization), and additional testcases will be
- added as we are able to identify other typical problem cases. These
- test cases will serve as a benchmark by which we can compare debug
- mode implementations.</p></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.debug_mode.design.other"></a>Other Implementations</h3></div></div></div><p>
- </p><p> There are several existing implementations of debug modes for C++
- standard library implementations, although none of them directly
- supports debugging for programs using libstdc++. The existing
- implementations include:</p><div class="itemizedlist"><ul type="disc"><li><p><a class="ulink" href="http://www.mathcs.sjsu.edu/faculty/horstman/safestl.html" target="_top">SafeSTL</a>:
- SafeSTL was the original debugging version of the Standard Template
- Library (STL), implemented by Cay S. Horstmann on top of the
- Hewlett-Packard STL. Though it inspired much work in this area, it
- has not been kept up-to-date for use with modern compilers or C++
- standard library implementations.</p></li><li><p><a class="ulink" href="http://www.stlport.org/" target="_top">STLport</a>: STLport is a free
- implementation of the C++ standard library derived from the <a class="ulink" href="http://www.sgi.com/tech/stl/" target="_top">SGI implementation</a>, and
- ported to many other platforms. It includes a debug mode that uses a
- wrapper model (that in some way inspired the libstdc++ debug mode
- design), although at the time of this writing the debug mode is
- somewhat incomplete and meets only the "Full user recompilation" (2)
- recompilation guarantee by requiring the user to link against a
- different library in debug mode vs. release mode.</p></li><li><p><a class="ulink" href="http://www.metrowerks.com/mw/default.htm" target="_top">Metrowerks
- CodeWarrior</a>: The C++ standard library that ships with Metrowerks
- CodeWarrior includes a debug mode. It is a full debug-mode
- implementation (including debugging for CodeWarrior extensions) and
- is easy to use, although it meets only the "Full recompilation" (1)
- recompilation guarantee.</p></li></ul></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch30s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="debug_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="parallel_mode.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Using </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 31. Parallel Mode</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s02.html
deleted file mode 100644
index 39c6f2aae..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s02.html
+++ /dev/null
@@ -1,11 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Semantics</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; parallel&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="parallel_mode.html" title="Chapter 31. Parallel Mode" /><link rel="prev" href="parallel_mode.html" title="Chapter 31. Parallel Mode" /><link rel="next" href="bk01pt12ch31s03.html" title="Using" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Semantics</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="parallel_mode.html">Prev</a> </td><th width="60%" align="center">Chapter 31. Parallel Mode</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch31s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.parallel_mode.semantics"></a>Semantics</h2></div></div></div><p> The parallel mode STL algorithms are currently not exception-safe,
-i.e. user-defined functors must not throw exceptions.
-Also, the order of execution is not guaranteed for some functions, of course.
-Therefore, user-defined functors should not have any concurrent side effects.
-</p><p> Since the current GCC OpenMP implementation does not support
-OpenMP parallel regions in concurrent threads,
-it is not possible to call parallel STL algorithm in
-concurrent threads, either.
-It might work with other compilers, though.</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="parallel_mode.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="parallel_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch31s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 31. Parallel Mode </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Using</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s03.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s03.html
deleted file mode 100644
index ddd145bd3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s03.html
+++ /dev/null
@@ -1,66 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Using</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; parallel&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="parallel_mode.html" title="Chapter 31. Parallel Mode" /><link rel="prev" href="bk01pt12ch31s02.html" title="Semantics" /><link rel="next" href="bk01pt12ch31s04.html" title="Design" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Using</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch31s02.html">Prev</a> </td><th width="60%" align="center">Chapter 31. Parallel Mode</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch31s04.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.parallel_mode.using"></a>Using</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="parallel_mode.using.prereq_flags"></a>Prerequisite Compiler Flags</h3></div></div></div><p>
- Any use of parallel functionality requires additional compiler
- and runtime support, in particular support for OpenMP. Adding this support is
- not difficult: just compile your application with the compiler
- flag <code class="literal">-fopenmp</code>. This will link
- in <code class="code">libgomp</code>, the GNU
- OpenMP <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libgomp/" target="_top">implementation</a>,
- whose presence is mandatory.
-</p><p>
-In addition, hardware that supports atomic operations and a compiler
- capable of producing atomic operations is mandatory: GCC defaults to no
- support for atomic operations on some common hardware
- architectures. Activating atomic operations may require explicit
- compiler flags on some targets (like sparc and x86), such
- as <code class="literal">-march=i686</code>,
- <code class="literal">-march=native</code> or <code class="literal">-mcpu=v9</code>. See
- the GCC manual for more information.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="parallel_mode.using.parallel_mode"></a>Using Parallel Mode</h3></div></div></div><p>
- To use the libstdc++ parallel mode, compile your application with
- the prerequisite flags as detailed above, and in addition
- add <code class="constant">-D_GLIBCXX_PARALLEL</code>. This will convert all
- use of the standard (sequential) algorithms to the appropriate parallel
- equivalents. Please note that this doesn't necessarily mean that
- everything will end up being executed in a parallel manner, but
- rather that the heuristics and settings coded into the parallel
- versions will be used to determine if all, some, or no algorithms
- will be executed using parallel variants.
-</p><p>Note that the <code class="constant">_GLIBCXX_PARALLEL</code> define may change the
- sizes and behavior of standard class templates such as
- <code class="function">std::search</code>, and therefore one can only link code
- compiled with parallel mode and code compiled without parallel mode
- if no instantiation of a container is passed between the two
- translation units. Parallel mode functionality has distinct linkage,
- and cannot be confused with normal mode symbols.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="parallel_mode.using.specific"></a>Using Specific Parallel Components</h3></div></div></div><p>When it is not feasible to recompile your entire application, or
- only specific algorithms need to be parallel-aware, individual
- parallel algorithms can be made available explicitly. These
- parallel algorithms are functionally equivalent to the standard
- drop-in algorithms used in parallel mode, but they are available in
- a separate namespace as GNU extensions and may be used in programs
- compiled with either release mode or with parallel mode.
-</p><p>An example of using a parallel version
-of <code class="function">std::sort</code>, but no other parallel algorithms, is:
-</p><pre class="programlisting">
-#include &lt;vector&gt;
-#include &lt;parallel/algorithm&gt;
-
-int main()
-{
- std::vector&lt;int&gt; v(100);
-
- // ...
-
- // Explicitly force a call to parallel sort.
- __gnu_parallel::sort(v.begin(), v.end());
- return 0;
-}
-</pre><p>
-Then compile this code with the prerequisite compiler flags
-(<code class="literal">-fopenmp</code> and any necessary architecture-specific
-flags for atomic operations.)
-</p><p> The following table provides the names and headers of all the
- parallel algorithms that can be used in a similar manner:
-</p><div class="table"><a id="id388611"></a><p class="title"><b>Table 31.1. Parallel Algorithms</b></p><div class="table-contents"><table summary="Parallel Algorithms" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><thead><tr><th align="left">Algorithm</th><th align="left">Header</th><th align="left">Parallel algorithm</th><th align="left">Parallel header</th></tr></thead><tbody><tr><td align="left"><code class="function">std::accumulate</code></td><td align="left"><code class="filename">numeric</code></td><td align="left"><code class="function">__gnu_parallel::accumulate</code></td><td align="left"><code class="filename">parallel/numeric</code></td></tr><tr><td align="left"><code class="function">std::adjacent_difference</code></td><td align="left"><code class="filename">numeric</code></td><td align="left"><code class="function">__gnu_parallel::adjacent_difference</code></td><td align="left"><code class="filename">parallel/numeric</code></td></tr><tr><td align="left"><code class="function">std::inner_product</code></td><td align="left"><code class="filename">numeric</code></td><td align="left"><code class="function">__gnu_parallel::inner_product</code></td><td align="left"><code class="filename">parallel/numeric</code></td></tr><tr><td align="left"><code class="function">std::partial_sum</code></td><td align="left"><code class="filename">numeric</code></td><td align="left"><code class="function">__gnu_parallel::partial_sum</code></td><td align="left"><code class="filename">parallel/numeric</code></td></tr><tr><td align="left"><code class="function">std::adjacent_find</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::adjacent_find</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::count</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::count</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::count_if</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::count_if</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::equal</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::equal</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::find</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::find</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::find_if</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::find_if</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::find_first_of</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::find_first_of</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::for_each</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::for_each</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::generate</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::generate</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::generate_n</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::generate_n</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::lexicographical_compare</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::lexicographical_compare</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::mismatch</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::mismatch</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::search</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::search</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::search_n</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::search_n</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::transform</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::transform</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::replace</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::replace</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::replace_if</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::replace_if</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::max_element</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::max_element</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::merge</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::merge</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::min_element</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::min_element</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::nth_element</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::nth_element</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::partial_sort</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::partial_sort</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::partition</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::partition</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::random_shuffle</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::random_shuffle</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::set_union</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::set_union</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::set_intersection</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::set_intersection</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::set_symmetric_difference</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::set_symmetric_difference</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::set_difference</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::set_difference</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::sort</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::sort</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::stable_sort</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::stable_sort</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr><tr><td align="left"><code class="function">std::unique_copy</code></td><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="function">__gnu_parallel::unique_copy</code></td><td align="left"><code class="filename">parallel/algorithm</code></td></tr></tbody></table></div></div><br class="table-break" /></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch31s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="parallel_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch31s04.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Semantics </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Design</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s04.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s04.html
deleted file mode 100644
index 40b2ad594..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s04.html
+++ /dev/null
@@ -1,213 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Design</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; parallel&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="parallel_mode.html" title="Chapter 31. Parallel Mode" /><link rel="prev" href="bk01pt12ch31s03.html" title="Using" /><link rel="next" href="bk01pt12ch31s05.html" title="Testing" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Design</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch31s03.html">Prev</a> </td><th width="60%" align="center">Chapter 31. Parallel Mode</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch31s05.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.parallel_mode.design"></a>Design</h2></div></div></div><p>
- </p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.parallel_mode.design.intro"></a>Interface Basics</h3></div></div></div><p>
-All parallel algorithms are intended to have signatures that are
-equivalent to the ISO C++ algorithms replaced. For instance, the
-<code class="function">std::adjacent_find</code> function is declared as:
-</p><pre class="programlisting">
-namespace std
-{
- template&lt;typename _FIter&gt;
- _FIter
- adjacent_find(_FIter, _FIter);
-}
-</pre><p>
-Which means that there should be something equivalent for the parallel
-version. Indeed, this is the case:
-</p><pre class="programlisting">
-namespace std
-{
- namespace __parallel
- {
- template&lt;typename _FIter&gt;
- _FIter
- adjacent_find(_FIter, _FIter);
-
- ...
- }
-}
-</pre><p>But.... why the ellipses?
-</p><p> The ellipses in the example above represent additional overloads
-required for the parallel version of the function. These additional
-overloads are used to dispatch calls from the ISO C++ function
-signature to the appropriate parallel function (or sequential
-function, if no parallel functions are deemed worthy), based on either
-compile-time or run-time conditions.
-</p><p> The available signature options are specific for the different
-algorithms/algorithm classes.</p><p> The general view of overloads for the parallel algorithms look like this:
-</p><div class="itemizedlist"><ul type="disc"><li><p>ISO C++ signature</p></li><li><p>ISO C++ signature + sequential_tag argument</p></li><li><p>ISO C++ signature + algorithm-specific tag type
- (several signatures)</p></li></ul></div><p> Please note that the implementation may use additional functions
-(designated with the <code class="code">_switch</code> suffix) to dispatch from the
-ISO C++ signature to the correct parallel version. Also, some of the
-algorithms do not have support for run-time conditions, so the last
-overload is therefore missing.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.parallel_mode.design.tuning"></a>Configuration and Tuning</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="parallel_mode.design.tuning.omp"></a>Setting up the OpenMP Environment</h4></div></div></div><p>
-Several aspects of the overall runtime environment can be manipulated
-by standard OpenMP function calls.
-</p><p>
-To specify the number of threads to be used for the algorithms globally,
-use the function <code class="function">omp_set_num_threads</code>. An example:
-</p><pre class="programlisting">
-#include &lt;stdlib.h&gt;
-#include &lt;omp.h&gt;
-
-int main()
-{
- // Explicitly set number of threads.
- const int threads_wanted = 20;
- omp_set_dynamic(false);
- omp_set_num_threads(threads_wanted);
-
- // Call parallel mode algorithms.
-
- return 0;
-}
-</pre><p>
- Some algorithms allow the number of threads being set for a particular call,
- by augmenting the algorithm variant.
- See the next section for further information.
-</p><p>
-Other parts of the runtime environment able to be manipulated include
-nested parallelism (<code class="function">omp_set_nested</code>), schedule kind
-(<code class="function">omp_set_schedule</code>), and others. See the OpenMP
-documentation for more information.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="parallel_mode.design.tuning.compile"></a>Compile Time Switches</h4></div></div></div><p>
-To force an algorithm to execute sequentially, even though parallelism
-is switched on in general via the macro <code class="constant">_GLIBCXX_PARALLEL</code>,
-add <code class="classname">__gnu_parallel::sequential_tag()</code> to the end
-of the algorithm's argument list.
-</p><p>
-Like so:
-</p><pre class="programlisting">
-std::sort(v.begin(), v.end(), __gnu_parallel::sequential_tag());
-</pre><p>
-Some parallel algorithm variants can be excluded from compilation by
-preprocessor defines. See the doxygen documentation on
-<code class="code">compiletime_settings.h</code> and <code class="code">features.h</code> for details.
-</p><p>
-For some algorithms, the desired variant can be chosen at compile-time by
-appending a tag object. The available options are specific to the particular
-algorithm (class).
-</p><p>
-For the "embarrassingly parallel" algorithms, there is only one "tag object
-type", the enum _Parallelism.
-It takes one of the following values,
-<code class="code">__gnu_parallel::parallel_tag</code>,
-<code class="code">__gnu_parallel::balanced_tag</code>,
-<code class="code">__gnu_parallel::unbalanced_tag</code>,
-<code class="code">__gnu_parallel::omp_loop_tag</code>,
-<code class="code">__gnu_parallel::omp_loop_static_tag</code>.
-This means that the actual parallelization strategy is chosen at run-time.
-(Choosing the variants at compile-time will come soon.)
-</p><p>
-For the following algorithms in general, we have
-<code class="code">__gnu_parallel::parallel_tag</code> and
-<code class="code">__gnu_parallel::default_parallel_tag</code>, in addition to
-<code class="code">__gnu_parallel::sequential_tag</code>.
-<code class="code">__gnu_parallel::default_parallel_tag</code> chooses the default
-algorithm at compiletime, as does omitting the tag.
-<code class="code">__gnu_parallel::parallel_tag</code> postpones the decision to runtime
-(see next section).
-For all tags, the number of threads desired for this call can optionally be
-passed to the respective tag's constructor.
-</p><p>
-The <code class="code">multiway_merge</code> algorithm comes with the additional choices,
-<code class="code">__gnu_parallel::exact_tag</code> and
-<code class="code">__gnu_parallel::sampling_tag</code>.
-Exact and sampling are the two available splitting strategies.
-</p><p>
-For the <code class="code">sort</code> and <code class="code">stable_sort</code> algorithms, there are
-several additional choices, namely
-<code class="code">__gnu_parallel::multiway_mergesort_tag</code>,
-<code class="code">__gnu_parallel::multiway_mergesort_exact_tag</code>,
-<code class="code">__gnu_parallel::multiway_mergesort_sampling_tag</code>,
-<code class="code">__gnu_parallel::quicksort_tag</code>, and
-<code class="code">__gnu_parallel::balanced_quicksort_tag</code>.
-Multiway mergesort comes with the two splitting strategies for multi-way
-merging. The quicksort options cannot be used for <code class="code">stable_sort</code>.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="parallel_mode.design.tuning.settings"></a>Run Time Settings and Defaults</h4></div></div></div><p>
-The default parallelization strategy, the choice of specific algorithm
-strategy, the minimum threshold limits for individual parallel
-algorithms, and aspects of the underlying hardware can be specified as
-desired via manipulation
-of <code class="classname">__gnu_parallel::_Settings</code> member data.
-</p><p>
-First off, the choice of parallelization strategy: serial, parallel,
-or heuristically deduced. This corresponds
-to <code class="code">__gnu_parallel::_Settings::algorithm_strategy</code> and is a
-value of enum <span class="type">__gnu_parallel::_AlgorithmStrategy</span>
-type. Choices
-include: <span class="type">heuristic</span>, <span class="type">force_sequential</span>,
-and <span class="type">force_parallel</span>. The default is <span class="type">heuristic</span>.
-</p><p>
-Next, the sub-choices for algorithm variant, if not fixed at compile-time.
-Specific algorithms like <code class="function">find</code> or <code class="function">sort</code>
-can be implemented in multiple ways: when this is the case,
-a <code class="classname">__gnu_parallel::_Settings</code> member exists to
-pick the default strategy. For
-example, <code class="code">__gnu_parallel::_Settings::sort_algorithm</code> can
-have any values of
-enum <span class="type">__gnu_parallel::_SortAlgorithm</span>: <span class="type">MWMS</span>, <span class="type">QS</span>,
-or <span class="type">QS_BALANCED</span>.
-</p><p>
-Likewise for setting the minimal threshold for algorithm
-parallelization. Parallelism always incurs some overhead. Thus, it is
-not helpful to parallelize operations on very small sets of
-data. Because of this, measures are taken to avoid parallelizing below
-a certain, pre-determined threshold. For each algorithm, a minimum
-problem size is encoded as a variable in the
-active <code class="classname">__gnu_parallel::_Settings</code> object. This
-threshold variable follows the following naming scheme:
-<code class="code">__gnu_parallel::_Settings::[algorithm]_minimal_n</code>. So,
-for <code class="function">fill</code>, the threshold variable
-is <code class="code">__gnu_parallel::_Settings::fill_minimal_n</code>,
-</p><p>
-Finally, hardware details like L1/L2 cache size can be hardwired
-via <code class="code">__gnu_parallel::_Settings::L1_cache_size</code> and friends.
-</p><p>
-</p><p>
-All these configuration variables can be changed by the user, if
-desired.
-There exists one global instance of the class <code class="classname">_Settings</code>,
-i. e. it is a singleton. It can be read and written by calling
-<code class="code">__gnu_parallel::_Settings::get</code> and
-<code class="code">__gnu_parallel::_Settings::set</code>, respectively.
-Please note that the first call return a const object, so direct manipulation
-is forbidden.
-See <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00640.html" target="_top">
- <code class="filename">settings.h</code></a>
-for complete details.
-</p><p>
-A small example of tuning the default:
-</p><pre class="programlisting">
-#include &lt;parallel/algorithm&gt;
-#include &lt;parallel/settings.h&gt;
-
-int main()
-{
- __gnu_parallel::_Settings s;
- s.algorithm_strategy = __gnu_parallel::force_parallel;
- __gnu_parallel::_Settings::set(s);
-
- // Do work... all algorithms will be parallelized, always.
-
- return 0;
-}
-</pre></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.parallel_mode.design.impl"></a>Implementation Namespaces</h3></div></div></div><p> One namespace contain versions of code that are always
-explicitly sequential:
-<code class="code">__gnu_serial</code>.
-</p><p> Two namespaces contain the parallel mode:
-<code class="code">std::__parallel</code> and <code class="code">__gnu_parallel</code>.
-</p><p> Parallel implementations of standard components, including
-template helpers to select parallelism, are defined in <code class="code">namespace
-std::__parallel</code>. For instance, <code class="function">std::transform</code> from <code class="filename">algorithm</code> has a parallel counterpart in
-<code class="function">std::__parallel::transform</code> from <code class="filename">parallel/algorithm</code>. In addition, these parallel
-implementations are injected into <code class="code">namespace
-__gnu_parallel</code> with using declarations.
-</p><p> Support and general infrastructure is in <code class="code">namespace
-__gnu_parallel</code>.
-</p><p> More information, and an organized index of types and functions
-related to the parallel mode on a per-namespace basis, can be found in
-the generated source documentation.
-</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch31s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="parallel_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch31s05.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Using </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Testing</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s05.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s05.html
deleted file mode 100644
index d0dce191a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch31s05.html
+++ /dev/null
@@ -1,26 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Testing</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; parallel&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="parallel_mode.html" title="Chapter 31. Parallel Mode" /><link rel="prev" href="bk01pt12ch31s04.html" title="Design" /><link rel="next" href="ext_allocators.html" title="Chapter 32. Allocators" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Testing</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch31s04.html">Prev</a> </td><th width="60%" align="center">Chapter 31. Parallel Mode</th><td width="20%" align="right"> <a accesskey="n" href="ext_allocators.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.parallel_mode.test"></a>Testing</h2></div></div></div><p>
- Both the normal conformance and regression tests and the
- supplemental performance tests work.
- </p><p>
- To run the conformance and regression tests with the parallel mode
- active,
- </p><pre class="screen">
- <strong class="userinput"><code>make check-parallel</code></strong>
- </pre><p>
- The log and summary files for conformance testing are in the
- <code class="filename">testsuite/parallel</code> directory.
- </p><p>
- To run the performance tests with the parallel mode active,
- </p><pre class="screen">
- <strong class="userinput"><code>make check-performance-parallel</code></strong>
- </pre><p>
- The result file for performance testing are in the
- <code class="filename">testsuite</code> directory, in the file
- <code class="filename">libstdc++_performance.sum</code>. In addition, the
- policy-based containers have their own visualizations, which have
- additional software dependencies than the usual bare-boned text
- file, and can be generated by using the <code class="code">make
- doc-performance</code> rule in the testsuite's Makefile.
-</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch31s04.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="parallel_mode.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ext_allocators.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Design </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 32. Allocators</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch33s02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch33s02.html
deleted file mode 100644
index 038488841..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch33s02.html
+++ /dev/null
@@ -1,43 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>HP/SGI</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="ext_containers.html" title="Chapter 33. Containers" /><link rel="prev" href="ext_containers.html" title="Chapter 33. Containers" /><link rel="next" href="bk01pt12ch33s03.html" title="Deprecated HP/SGI" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">HP/SGI</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ext_containers.html">Prev</a> </td><th width="60%" align="center">Chapter 33. Containers</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch33s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.containers.sgi"></a>HP/SGI</h2></div></div></div><p>
- </p><p>A few extensions and nods to backwards-compatibility have been made with
- containers. Those dealing with older SGI-style allocators are dealt with
- elsewhere. The remaining ones all deal with bits:
-</p><p>The old pre-standard <code class="code">bit_vector</code> class is present for
- backwards compatibility. It is simply a typedef for the
- <code class="code">vector&lt;bool&gt;</code> specialization.
-</p><p>The <code class="code">bitset</code> class has a number of extensions, described in the
- rest of this item. First, we'll mention that this implementation of
- <code class="code">bitset&lt;N&gt;</code> is specialized for cases where N number of
- bits will fit into a single word of storage. If your choice of N is
- within that range (&lt;=32 on i686-pc-linux-gnu, for example), then all
- of the operations will be faster.
-</p><p>There are
- versions of single-bit test, set, reset, and flip member functions which
- do no range-checking. If we call them member functions of an instantiation
- of "bitset&lt;N&gt;," then their names and signatures are:
-</p><pre class="programlisting">
- bitset&lt;N&gt;&amp; _Unchecked_set (size_t pos);
- bitset&lt;N&gt;&amp; _Unchecked_set (size_t pos, int val);
- bitset&lt;N&gt;&amp; _Unchecked_reset (size_t pos);
- bitset&lt;N&gt;&amp; _Unchecked_flip (size_t pos);
- bool _Unchecked_test (size_t pos);
- </pre><p>Note that these may in fact be removed in the future, although we have
- no present plans to do so (and there doesn't seem to be any immediate
- reason to).
-</p><p>The semantics of member function <code class="code">operator[]</code> are not specified
- in the C++ standard. A long-standing defect report calls for sensible
- obvious semantics, which are already implemented here: <code class="code">op[]</code>
- on a const bitset returns a bool, and for a non-const bitset returns a
- <code class="code">reference</code> (a nested type). However, this implementation does
- no range-checking on the index argument, which is in keeping with other
- containers' <code class="code">op[]</code> requirements. The defect report's proposed
- resolution calls for range-checking to be done. We'll just wait and see...
-</p><p>Finally, two additional searching functions have been added. They return
- the index of the first "on" bit, and the index of the first
- "on" bit that is after <code class="code">prev</code>, respectively:
-</p><pre class="programlisting">
- size_t _Find_first() const;
- size_t _Find_next (size_t prev) const;</pre><p>The same caveat given for the _Unchecked_* functions applies here also.
-</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ext_containers.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ext_containers.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch33s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 33. Containers </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Deprecated HP/SGI</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch33s03.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch33s03.html
deleted file mode 100644
index c1aa5dc40..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch33s03.html
+++ /dev/null
@@ -1,50 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Deprecated HP/SGI</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="ext_containers.html" title="Chapter 33. Containers" /><link rel="prev" href="bk01pt12ch33s02.html" title="HP/SGI" /><link rel="next" href="ext_utilities.html" title="Chapter 34. Utilities" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Deprecated HP/SGI</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch33s02.html">Prev</a> </td><th width="60%" align="center">Chapter 33. Containers</th><td width="20%" align="right"> <a accesskey="n" href="ext_utilities.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.containers.deprecated_sgi"></a>Deprecated HP/SGI</h2></div></div></div><p>
- The SGI hashing classes <code class="classname">hash_set</code> and
- <code class="classname">hash_set</code> have been deprecated by the
- unordered_set, unordered_multiset, unordered_map,
- unordered_multimap containers in TR1 and the upcoming C++0x, and
- may be removed in future releases.
- </p><p>The SGI headers</p><pre class="programlisting">
- &lt;hash_map&gt;
- &lt;hash_set&gt;
- &lt;rope&gt;
- &lt;slist&gt;
- &lt;rb_tree&gt;
- </pre><p>are all here;
- <code class="code">&lt;hash_map&gt;</code> and <code class="code">&lt;hash_set&gt;</code>
- are deprecated but available as backwards-compatible extensions,
- as discussed further below. <code class="code">&lt;rope&gt;</code> is the
- SGI specialization for large strings ("rope,"
- "large strings," get it? Love that geeky humor.)
- <code class="code">&lt;slist&gt;</code> is a singly-linked list, for when the
- doubly-linked <code class="code">list&lt;&gt;</code> is too much space
- overhead, and <code class="code">&lt;rb_tree&gt;</code> exposes the red-black
- tree classes used in the implementation of the standard maps and
- sets.
- </p><p>Each of the associative containers map, multimap, set, and multiset
- have a counterpart which uses a
- <a class="ulink" href="http://www.sgi.com/tech/stl/HashFunction.html" target="_top">hashing
- function</a> 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
- <a class="ulink" href="http://www.sgi.com/tech/stl/hash.html" target="_top">hash</a>.
- You should specialize this functor for your class, or define your own,
- before trying to use one of the hashing classes.
- </p><p>The hashing classes support all the usual associative container
- functions, as well as some extra constructors specifying the number
- of buckets, etc.
- </p><p>Why would you want to use a hashing class instead of the
- “<span class="quote">normal</span>”implementations? Matt Austern writes:
- </p><div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>[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.
- </em></span>
- </p></blockquote></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch33s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ext_containers.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ext_utilities.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">HP/SGI </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 34. Utilities</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch40s02.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch40s02.html
deleted file mode 100644
index 0a8bf611b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch40s02.html
+++ /dev/null
@@ -1,41 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Implementation</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="ext_concurrency.html" title="Chapter 40. Concurrency" /><link rel="prev" href="ext_concurrency.html" title="Chapter 40. Concurrency" /><link rel="next" href="bk01pt12ch40s03.html" title="Use" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Implementation</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ext_concurrency.html">Prev</a> </td><th width="60%" align="center">Chapter 40. Concurrency</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch40s03.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.concurrency.impl"></a>Implementation</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.concurrency.impl.atomic_fallbacks"></a>Using Builtin Atomic Functions</h3></div></div></div><p>The functions for atomic operations described above are either
-implemented via compiler intrinsics (if the underlying host is
-capable) or by library fallbacks.</p><p>Compiler intrinsics (builtins) are always preferred. However, as
-the compiler builtins for atomics are not universally implemented,
-using them directly is problematic, and can result in undefined
-function calls. (An example of an undefined symbol from the use
-of <code class="code">__sync_fetch_and_add</code> on an unsupported host is a
-missing reference to <code class="code">__sync_fetch_and_add_4</code>.)
-</p><p>In addition, on some hosts the compiler intrinsics are enabled
-conditionally, via the <code class="code">-march</code> command line flag. This makes
-usage vary depending on the target hardware and the flags used during
-compile.
-</p><p>
-If builtins are possible for bool-sized integral types,
-<code class="code">_GLIBCXX_ATOMIC_BUILTINS_1</code> will be defined.
-If builtins are possible for int-sized integral types,
-<code class="code">_GLIBCXX_ATOMIC_BUILTINS_4</code> will be defined.
-</p><p>For the following hosts, intrinsics are enabled by default.
-</p><div class="itemizedlist"><ul type="disc"><li><p>alpha</p></li><li><p>ia64</p></li><li><p>powerpc</p></li><li><p>s390</p></li></ul></div><p>For others, some form of <code class="code">-march</code> may work. On
-non-ancient x86 hardware, <code class="code">-march=native</code> usually does the
-trick.</p><p> For hosts without compiler intrinsics, but with capable
-hardware, hand-crafted assembly is selected. This is the case for the following hosts:
-</p><div class="itemizedlist"><ul type="disc"><li><p>cris</p></li><li><p>hppa</p></li><li><p>i386</p></li><li><p>i486</p></li><li><p>m48k</p></li><li><p>mips</p></li><li><p>sparc</p></li></ul></div><p>And for the rest, a simulated atomic lock via pthreads.
-</p><p> Detailed information about compiler intrinsics for atomic operations can be found in the GCC <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html" target="_top"> documentation</a>.
-</p><p> More details on the library fallbacks from the porting <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/porting.html#Thread%20safety" target="_top">section</a>.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.concurrency.impl.thread"></a>Thread Abstraction</h3></div></div></div><p>A thin layer above IEEE 1003.1 (i.e. pthreads) is used to abstract
-the thread interface for GCC. This layer is called "gthread," and is
-comprised of one header file that wraps the host's default thread layer with
-a POSIX-like interface.
-</p><p> The file &lt;gthr-default.h&gt; points to the deduced wrapper for
-the current host. In libstdc++ implementation files,
-&lt;bits/gthr.h&gt; is used to select the proper gthreads file.
-</p><p>Within libstdc++ sources, all calls to underlying thread functionality
-use this layer. More detail as to the specific interface can be found in the source <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/gthr_8h-source.html" target="_top">documentation</a>.
-</p><p>By design, the gthread layer is interoperable with the types,
-functions, and usage found in the usual &lt;pthread.h&gt; file,
-including <code class="code">pthread_t</code>, <code class="code">pthread_once_t</code>, <code class="code">pthread_create</code>,
-etc.
-</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ext_concurrency.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ext_concurrency.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch40s03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 40. Concurrency </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Use</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch40s03.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch40s03.html
deleted file mode 100644
index 115aa9f55..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12ch40s03.html
+++ /dev/null
@@ -1,37 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Use</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="ext_concurrency.html" title="Chapter 40. Concurrency" /><link rel="prev" href="bk01pt12ch40s02.html" title="Implementation" /><link rel="next" href="appendix_contributing.html" title="Appendix A.  Contributing" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Use</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch40s02.html">Prev</a> </td><th width="60%" align="center">Chapter 40. Concurrency</th><td width="20%" align="right"> <a accesskey="n" href="appendix_contributing.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.concurrency.use"></a>Use</h2></div></div></div><p>Typical usage of the last two constructs is demonstrated as follows:
-</p><pre class="programlisting">
-#include &lt;ext/concurrence.h&gt;
-
-namespace
-{
- __gnu_cxx::__mutex safe_base_mutex;
-} // anonymous namespace
-
-namespace other
-{
- void
- foo()
- {
- __gnu_cxx::__scoped_lock sentry(safe_base_mutex);
- for (int i = 0; i &lt; max; ++i)
- {
- _Safe_iterator_base* __old = __iter;
- __iter = __iter-&lt;_M_next;
- __old-&lt;_M_detach_single();
- }
-}
-</pre><p>In this sample code, an anonymous namespace is used to keep
-the <code class="code">__mutex</code> private to the compilation unit,
-and <code class="code">__scoped_lock</code> is used to guard access to the critical
-section within the for loop, locking the mutex on creation and freeing
-the mutex as control moves out of this block.
-</p><p>Several exception classes are used to keep track of
-concurrence-related errors. These classes
-are: <code class="code">__concurrence_lock_error</code>, <code class="code">__concurrence_unlock_error</code>, <code class="code">__concurrence_wait_error</code>,
-and <code class="code">__concurrence_broadcast_error</code>.
-</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch40s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ext_concurrency.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="appendix_contributing.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Implementation </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix A. 
- Contributing
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12pr03.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12pr03.html
deleted file mode 100644
index 0dbbe5f03..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bk01pt12pr03.html
+++ /dev/null
@@ -1,27 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title></title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="extensions.html" title="Part XII.  Extensions" /><link rel="next" href="ext_compile_checks.html" title="Chapter 29. Compile Time Checks" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center"></th></tr><tr><td width="20%" align="left"><a accesskey="p" href="extensions.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="ext_compile_checks.html">Next</a></td></tr></table><hr /></div><div class="preface" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="id415391"></a></h2></div></div></div><p>
- 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.
-</p><p><span class="emphasis"><em>Before</em></span> you leap in and use any of these
-extensions, be aware of two things:
-</p><div class="orderedlist"><ol type="1"><li><p>
- Non-Standard means exactly that.
- </p><p>
- The behavior, and the very
- existence, of these extensions may change with little or no
- warning. (Ideally, the really good ones will appear in the next
- revision of C++.) Also, other platforms, other compilers, other
- versions of g++ or libstdc++ may not recognize these names, or
- treat them differently, or...
- </p></li><li><p>
- You should know how to <a class="ulink" href="XXX" target="_top">access
- these headers properly</a>.
- </p></li></ol></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="extensions.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ext_compile_checks.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part XII. 
- Extensions
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 29. Compile Time Checks</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bugs.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/bugs.html
deleted file mode 100644
index 9217b8a1e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/bugs.html
+++ /dev/null
@@ -1,330 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Bugs</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="status.html" title="Chapter 1. Status" /><link rel="prev" href="license.html" title="License" /><link rel="next" href="setup.html" title="Chapter 2. Setup" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Bugs</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="license.html">Prev</a> </td><th width="60%" align="center">Chapter 1. Status</th><td width="20%" align="right"> <a accesskey="n" href="setup.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.status.bugs"></a>Bugs</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.bugs.impl"></a>Implementation Bugs</h3></div></div></div><p>
- Information on known bugs, details on efforts to fix them, and
- fixed bugs are all available as part of the GCC bug tracking
- system, <a class="ulink" href="http://gcc.gnu.org/bugzilla" target="_top">bugzilla</a>, with the
- category set to <code class="literal">libstdc++</code>.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.bugs.iso"></a>Standard Bugs</h3></div></div></div><p>
- Everybody's got issues. Even the C++ Standard Library.
- </p><p>
- 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.
- </p><p>
- Here are the issues which have resulted in code changes to the library.
- The links are to the specific defect reports from a <span class="emphasis"><em>partial
- copy</em></span> of the Issues List. You can read the full version online
- at the <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/" target="_top">ISO C++
- Committee homepage</a>, linked to on the
- <a class="ulink" href="http://gcc.gnu.org/readings.html" target="_top">GCC "Readings"
- page</a>. If
- you spend a lot of time reading the issues, we recommend downloading
- the ZIP file and reading them locally.
- </p><p>
- (NB: <span class="emphasis"><em>partial copy</em></span> 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.)
- </p><p>
- 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
- <code class="constant">_GLIBCXX_RESOLVE_LIB_DEFECTS</code> for examples
- of style. Note that we usually do not make changes to the
- code until an issue has reached <a class="ulink" href="lwg-active.html#DR" target="_top">DR</a> status.
- </p><div class="variablelist"><dl><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#5" target="_top">5</a>:
- <span class="emphasis"><em>string::compare specification questionable</em></span>
- </span></dt><dd><p>This should be two overloaded functions rather than a single function.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#17" target="_top">17</a>:
- <span class="emphasis"><em>Bad bool parsing</em></span>
- </span></dt><dd><p>Apparently extracting Boolean values was messed up...
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#19" target="_top">19</a>:
- <span class="emphasis"><em>"Noconv" definition too vague</em></span>
- </span></dt><dd><p>If <code class="code">codecvt::do_in</code> returns <code class="code">noconv</code> there are
- no changes to the values in <code class="code">[to, to_limit)</code>.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#22" target="_top">22</a>:
- <span class="emphasis"><em>Member open vs flags</em></span>
- </span></dt><dd><p>Re-opening a file stream does <span class="emphasis"><em>not</em></span> clear the state flags.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-active.html#23" target="_top">23</a>:
- <span class="emphasis"><em>Num_get overflow result</em></span>
- </span></dt><dd><p>Implement the proposed resolution.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#25" target="_top">25</a>:
- <span class="emphasis"><em>String operator&lt;&lt; uses width() value wrong</em></span>
- </span></dt><dd><p>Padding issues.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#48" target="_top">48</a>:
- <span class="emphasis"><em>Use of non-existent exception constructor</em></span>
- </span></dt><dd><p>An instance of <code class="code">ios_base::failure</code> is constructed instead.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#49" target="_top">49</a>:
- <span class="emphasis"><em>Underspecification of ios_base::sync_with_stdio</em></span>
- </span></dt><dd><p>The return type is the <span class="emphasis"><em>previous</em></span> state of synchronization.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#50" target="_top">50</a>:
- <span class="emphasis"><em>Copy constructor and assignment operator of ios_base</em></span>
- </span></dt><dd><p>These members functions are declared <code class="code">private</code> and are
- thus inaccessible. Specifying the correct semantics of
- "copying stream state" was deemed too complicated.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#60" target="_top">60</a>:
- <span class="emphasis"><em>What is a formatted input function?</em></span>
- </span></dt><dd><p>This DR made many widespread changes to <code class="code">basic_istream</code>
- and <code class="code">basic_ostream</code> all of which have been implemented.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#63" target="_top">63</a>:
- <span class="emphasis"><em>Exception-handling policy for unformatted output</em></span>
- </span></dt><dd><p>Make the policy consistent with that of formatted input, unformatted
- input, and formatted output.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#68" target="_top">68</a>:
- <span class="emphasis"><em>Extractors for char* should store null at end</em></span>
- </span></dt><dd><p>And they do now. An editing glitch in the last item in the list of
- [27.6.1.2.3]/7.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#74" target="_top">74</a>:
- <span class="emphasis"><em>Garbled text for codecvt::do_max_length</em></span>
- </span></dt><dd><p>The text of the standard was gibberish. Typos gone rampant.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#75" target="_top">75</a>:
- <span class="emphasis"><em>Contradiction in codecvt::length's argument types</em></span>
- </span></dt><dd><p>Change the first parameter to <code class="code">stateT&amp;</code> and implement
- the new effects paragraph.
- </p></dd><dt><span class="term"><a class="ulink" href="lwg-defects.html#83" target="_top">83</a>:
- <span class="emphasis"><em>string::npos vs. string::max_size()</em></span>
- </span></dt><dd><p>Safety checks on the size of the string should test against
- <code class="code">max_size()</code> rather than <code class="code">npos</code>.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#90" target="_top">90</a>:
- <span class="emphasis"><em>Incorrect description of operator&gt;&gt; for strings</em></span>
- </span></dt><dd><p>The effect contain <code class="code">isspace(c,getloc())</code> which must be
- replaced by <code class="code">isspace(c,is.getloc())</code>.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#91" target="_top">91</a>:
- <span class="emphasis"><em>Description of operator&gt;&gt; and getline() for string&lt;&gt;
- might cause endless loop</em></span>
- </span></dt><dd><p>They behave as a formatted input function and as an unformatted
- input function, respectively (except that <code class="code">getline</code> is
- not required to set <code class="code">gcount</code>).
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#103" target="_top">103</a>:
- <span class="emphasis"><em>set::iterator is required to be modifiable, but this allows
- modification of keys.</em></span>
- </span></dt><dd><p>For associative containers where the value type is the same as
- the key type, both <code class="code">iterator</code> and <code class="code">const_iterator
- </code> are constant iterators.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#109" target="_top">109</a>:
- <span class="emphasis"><em>Missing binders for non-const sequence elements</em></span>
- </span></dt><dd><p>The <code class="code">binder1st</code> and <code class="code">binder2nd</code> didn't have an
- <code class="code">operator()</code> taking a non-const parameter.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#110" target="_top">110</a>:
- <span class="emphasis"><em>istreambuf_iterator::equal not const</em></span>
- </span></dt><dd><p>This was not a const member function. Note that the DR says to
- replace the function with a const one; we have instead provided an
- overloaded version with identical contents.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#117" target="_top">117</a>:
- <span class="emphasis"><em>basic_ostream uses nonexistent num_put member functions</em></span>
- </span></dt><dd><p><code class="code">num_put::put()</code> was overloaded on the wrong types.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#118" target="_top">118</a>:
- <span class="emphasis"><em>basic_istream uses nonexistent num_get member functions</em></span>
- </span></dt><dd><p>Same as 117, but for <code class="code">num_get::get()</code>.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#129" target="_top">129</a>:
- <span class="emphasis"><em>Need error indication from seekp() and seekg()</em></span>
- </span></dt><dd><p>These functions set <code class="code">failbit</code> on error now.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#136" target="_top">136</a>:
- <span class="emphasis"><em>seekp, seekg setting wrong streams?</em></span>
- </span></dt><dd><p><code class="code">seekp</code> should only set the output stream, and
- <code class="code">seekg</code> should only set the input stream.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#167" target="_top">167</a>:
- <span class="emphasis"><em>Improper use of traits_type::length()</em></span>
- </span></dt><dd><p><code class="code">op&lt;&lt;</code> with a <code class="code">const char*</code> was
- calculating an incorrect number of characters to write.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#169" target="_top">169</a>:
- <span class="emphasis"><em>Bad efficiency of overflow() mandated</em></span>
- </span></dt><dd><p>Grow efficiently the internal array object.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#171" target="_top">171</a>:
- <span class="emphasis"><em>Strange seekpos() semantics due to joint position</em></span>
- </span></dt><dd><p>Quite complex to summarize...
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#181" target="_top">181</a>:
- <span class="emphasis"><em>make_pair() unintended behavior</em></span>
- </span></dt><dd><p>This function used to take its arguments as reference-to-const, now
- it copies them (pass by value).
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#195" target="_top">195</a>:
- <span class="emphasis"><em>Should basic_istream::sentry's constructor ever set eofbit?</em></span>
- </span></dt><dd><p>Yes, it can, specifically if EOF is reached while skipping whitespace.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#211" target="_top">211</a>:
- <span class="emphasis"><em>operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</em></span>
- </span></dt><dd><p>If nothing is extracted into the string, <code class="code">op&gt;&gt;</code> now
- sets <code class="code">failbit</code> (which can cause an exception, etc., etc.).
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#214" target="_top">214</a>:
- <span class="emphasis"><em>set::find() missing const overload</em></span>
- </span></dt><dd><p>Both <code class="code">set</code> and <code class="code">multiset</code> were missing
- overloaded find, lower_bound, upper_bound, and equal_range functions
- for const instances.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#231" target="_top">231</a>:
- <span class="emphasis"><em>Precision in iostream?</em></span>
- </span></dt><dd><p>For conversion from a floating-point type, <code class="code">str.precision()</code>
- is specified in the conversion specification.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-active.html#233" target="_top">233</a>:
- <span class="emphasis"><em>Insertion hints in associative containers</em></span>
- </span></dt><dd><p>Implement N1780, first check before then check after, insert as close
- to hint as possible.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#235" target="_top">235</a>:
- <span class="emphasis"><em>No specification of default ctor for reverse_iterator</em></span>
- </span></dt><dd><p>The declaration of <code class="code">reverse_iterator</code> lists a default constructor.
- However, no specification is given what this constructor should do.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#241" target="_top">241</a>:
- <span class="emphasis"><em>Does unique_copy() require CopyConstructible and Assignable?</em></span>
- </span></dt><dd><p>Add a helper for forward_iterator/output_iterator, fix the existing
- one for input_iterator/output_iterator to not rely on Assignability.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#243" target="_top">243</a>:
- <span class="emphasis"><em>get and getline when sentry reports failure</em></span>
- </span></dt><dd><p>Store a null character only if the character array has a non-zero size.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#251" target="_top">251</a>:
- <span class="emphasis"><em>basic_stringbuf missing allocator_type</em></span>
- </span></dt><dd><p>This nested typedef was originally not specified.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#253" target="_top">253</a>:
- <span class="emphasis"><em>valarray helper functions are almost entirely useless</em></span>
- </span></dt><dd><p>Make the copy constructor and copy-assignment operator declarations
- public in gslice_array, indirect_array, mask_array, slice_array; provide
- definitions.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#265" target="_top">265</a>:
- <span class="emphasis"><em>std::pair::pair() effects overly restrictive</em></span>
- </span></dt><dd><p>The default ctor would build its members from copies of temporaries;
- now it simply uses their respective default ctors.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#266" target="_top">266</a>:
- <span class="emphasis"><em>bad_exception::~bad_exception() missing Effects clause</em></span>
- </span></dt><dd><p>The <code class="code">bad_</code>* classes no longer have destructors (they
- are trivial), since no description of them was ever given.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#271" target="_top">271</a>:
- <span class="emphasis"><em>basic_iostream missing typedefs</em></span>
- </span></dt><dd><p>The typedefs it inherits from its base classes can't be used, since
- (for example) <code class="code">basic_iostream&lt;T&gt;::traits_type</code> is ambiguous.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#275" target="_top">275</a>:
- <span class="emphasis"><em>Wrong type in num_get::get() overloads</em></span>
- </span></dt><dd><p>Similar to 118.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#280" target="_top">280</a>:
- <span class="emphasis"><em>Comparison of reverse_iterator to const reverse_iterator</em></span>
- </span></dt><dd><p>Add global functions with two template parameters.
- (NB: not added for now a templated assignment operator)
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#292" target="_top">292</a>:
- <span class="emphasis"><em>Effects of a.copyfmt (a)</em></span>
- </span></dt><dd><p>If <code class="code">(this == &amp;rhs)</code> do nothing.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#300" target="_top">300</a>:
- <span class="emphasis"><em>List::merge() specification incomplete</em></span>
- </span></dt><dd><p>If <code class="code">(this == &amp;x)</code> do nothing.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#303" target="_top">303</a>:
- <span class="emphasis"><em>Bitset input operator underspecified</em></span>
- </span></dt><dd><p>Basically, compare the input character to
- <code class="code">is.widen(0)</code> and <code class="code">is.widen(1)</code>.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#305" target="_top">305</a>:
- <span class="emphasis"><em>Default behavior of codecvt&lt;wchar_t, char,
- mbstate_t&gt;::length()</em></span>
- </span></dt><dd><p>Do not specify what <code class="code">codecvt&lt;wchar_t, char,
- mbstate_t&gt;::do_length</code> must return.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#328" target="_top">328</a>:
- <span class="emphasis"><em>Bad sprintf format modifier in
- money_put&lt;&gt;::do_put()</em></span>
- </span></dt><dd><p>Change the format string to "%.0Lf".
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#365" target="_top">365</a>:
- <span class="emphasis"><em>Lack of const-qualification in clause 27</em></span>
- </span></dt><dd><p>Add const overloads of <code class="code">is_open</code>.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-active.html#387" target="_top">387</a>:
- <span class="emphasis"><em>std::complex over-encapsulated</em></span>
- </span></dt><dd><p>Add the <code class="code">real(T)</code> and <code class="code">imag(T)</code>
- members; in C++0x mode, also adjust the existing
- <code class="code">real()</code> and <code class="code">imag()</code> members and
- free functions.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#389" target="_top">389</a>:
- <span class="emphasis"><em>Const overload of valarray::operator[] returns
- by value</em></span>
- </span></dt><dd><p>Change it to return a <code class="code">const T&amp;</code>.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-active.html#396" target="_top">396</a>:
- <span class="emphasis"><em>what are characters zero and one</em></span>
- </span></dt><dd><p>Implement the proposed resolution.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#402" target="_top">402</a>:
- <span class="emphasis"><em>Wrong new expression in [some_]allocator::construct</em></span>
- </span></dt><dd><p>Replace "new" with "::new".
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#409" target="_top">409</a>:
- <span class="emphasis"><em>Closing an fstream should clear the error state</em></span>
- </span></dt><dd><p>Have <code class="code">open</code> clear the error flags.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-active.html#431" target="_top">431</a>:
- <span class="emphasis"><em>Swapping containers with unequal allocators</em></span>
- </span></dt><dd><p>Implement Option 3, as per N1599.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#432" target="_top">432</a>:
- <span class="emphasis"><em>stringbuf::overflow() makes only one write position
- available</em></span>
- </span></dt><dd><p>Implement the resolution, beyond DR 169.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#434" target="_top">434</a>:
- <span class="emphasis"><em>bitset::to_string() hard to use</em></span>
- </span></dt><dd><p>Add three overloads, taking fewer template arguments.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#438" target="_top">438</a>:
- <span class="emphasis"><em>Ambiguity in the "do the right thing" clause</em></span>
- </span></dt><dd><p>Implement the resolution, basically cast less.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#453" target="_top">453</a>:
- <span class="emphasis"><em>basic_stringbuf::seekoff need not always fail for an empty stream</em></span>
- </span></dt><dd><p>Don't fail if the next pointer is null and newoff is zero.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#455" target="_top">455</a>:
- <span class="emphasis"><em>cerr::tie() and wcerr::tie() are overspecified</em></span>
- </span></dt><dd><p>Initialize cerr tied to cout and wcerr tied to wcout.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#464" target="_top">464</a>:
- <span class="emphasis"><em>Suggestion for new member functions in standard containers</em></span>
- </span></dt><dd><p>Add <code class="code">data()</code> to <code class="code">std::vector</code> and
- <code class="code">at(const key_type&amp;)</code> to <code class="code">std::map</code>.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#508" target="_top">508</a>:
- <span class="emphasis"><em>Bad parameters for ranlux64_base_01</em></span>
- </span></dt><dd><p>Fix the parameters.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-closed.html#512" target="_top">512</a>:
- <span class="emphasis"><em>Seeding subtract_with_carry_01 from a single unsigned long</em></span>
- </span></dt><dd><p>Construct a <code class="code">linear_congruential</code> engine and seed with it.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-closed.html#526" target="_top">526</a>:
- <span class="emphasis"><em>Is it undefined if a function in the standard changes in
- parameters?</em></span>
- </span></dt><dd><p>Use &amp;value.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#538" target="_top">538</a>:
- <span class="emphasis"><em>241 again: Does unique_copy() require CopyConstructible
- and Assignable?</em></span>
- </span></dt><dd><p>In case of input_iterator/output_iterator rely on Assignability of
- input_iterator' value_type.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#541" target="_top">541</a>:
- <span class="emphasis"><em>shared_ptr template assignment and void</em></span>
- </span></dt><dd><p>Add an auto_ptr&lt;void&gt; specialization.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#543" target="_top">543</a>:
- <span class="emphasis"><em>valarray slice default constructor</em></span>
- </span></dt><dd><p>Follow the straightforward proposed resolution.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#550" target="_top">550</a>:
- <span class="emphasis"><em>What should the return type of pow(float,int) be?</em></span>
- </span></dt><dd><p>In C++0x mode, remove the pow(float,int), etc., signatures.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#586" target="_top">586</a>:
- <span class="emphasis"><em>string inserter not a formatted function</em></span>
- </span></dt><dd><p>Change it to be a formatted output function (i.e. catch exceptions).
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#596" target="_top">596</a>:
- <span class="emphasis"><em>27.8.1.3 Table 112 omits "a+" and "a+b" modes</em></span>
- </span></dt><dd><p>Add the missing modes to fopen_mode.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#660" target="_top">660</a>:
- <span class="emphasis"><em>Missing bitwise operations</em></span>
- </span></dt><dd><p>Add the missing operations.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-active.html#691" target="_top">691</a>:
- <span class="emphasis"><em>const_local_iterator cbegin, cend missing from TR1</em></span>
- </span></dt><dd><p>In C++0x mode add cbegin(size_type) and cend(size_type)
- to the unordered containers.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#693" target="_top">693</a>:
- <span class="emphasis"><em>std::bitset::all() missing</em></span>
- </span></dt><dd><p>Add it, consistently with the discussion.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#695" target="_top">695</a>:
- <span class="emphasis"><em>ctype&lt;char&gt;::classic_table() not accessible</em></span>
- </span></dt><dd><p>Make the member functions table and classic_table public.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#761" target="_top">761</a>:
- <span class="emphasis"><em>unordered_map needs an at() member function</em></span>
- </span></dt><dd><p>In C++0x mode, add at() and at() const.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#775" target="_top">775</a>:
- <span class="emphasis"><em>Tuple indexing should be unsigned?</em></span>
- </span></dt><dd><p>Implement the int -&gt; size_t replacements.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-active.html#776" target="_top">776</a>:
- <span class="emphasis"><em>Undescribed assign function of std::array</em></span>
- </span></dt><dd><p>In C++0x mode, remove assign, add fill.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-defects.html#781" target="_top">781</a>:
- <span class="emphasis"><em>std::complex should add missing C99 functions</em></span>
- </span></dt><dd><p>In C++0x mode, add std::proj.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-active.html#809" target="_top">809</a>:
- <span class="emphasis"><em>std::swap should be overloaded for array types</em></span>
- </span></dt><dd><p>Add the overload.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-active.html#844" target="_top">844</a>:
- <span class="emphasis"><em>complex pow return type is ambiguous</em></span>
- </span></dt><dd><p>In C++0x mode, remove the pow(complex&lt;T&gt;, int) signature.
- </p></dd><dt><span class="term"><a class="ulink" href="../ext/lwg-active.html#853" target="_top">853</a>:
- <span class="emphasis"><em>to_string needs updating with zero and one</em></span>
- </span></dt><dd><p>Update / add the signatures.
- </p></dd></dl></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="license.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="status.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="setup.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">License </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 2. Setup</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/codecvt.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/codecvt.html
deleted file mode 100644
index c65f960fe..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/codecvt.html
+++ /dev/null
@@ -1,379 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>codecvt</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; codecvt&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="facets.html" title="Chapter 15. Facets aka Categories" /><link rel="prev" href="facets.html" title="Chapter 15. Facets aka Categories" /><link rel="next" href="messages.html" title="messages" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">codecvt</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="facets.html">Prev</a> </td><th width="60%" align="center">Chapter 15. Facets aka Categories</th><td width="20%" align="right"> <a accesskey="n" href="messages.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.localization.facet.codecvt"></a>codecvt</h2></div></div></div><p>
-The standard class codecvt attempts to address conversions between
-different character encoding schemes. In particular, the standard
-attempts to detail conversions between the implementation-defined wide
-characters (hereafter referred to as wchar_t) and the standard type
-char that is so beloved in classic “<span class="quote">C</span>” (which can now be
-referred to as narrow characters.) This document attempts to describe
-how the GNU libstdc++ implementation deals with the conversion between
-wide and narrow characters, and also presents a framework for dealing
-with the huge number of other encodings that iconv can convert,
-including Unicode and UTF8. Design issues and requirements are
-addressed, and examples of correct usage for both the required
-specializations for wide and narrow characters and the
-implementation-provided extended functionality are given.
-</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.codecvt.req"></a>Requirements</h3></div></div></div><p>
-Around page 425 of the C++ Standard, this charming heading comes into view:
-</p><div class="blockquote"><blockquote class="blockquote"><p>
-22.2.1.5 - Template class codecvt
-</p></blockquote></div><p>
-The text around the codecvt definition gives some clues:
-</p><div class="blockquote"><blockquote class="blockquote"><p>
-<span class="emphasis"><em>
--1- The class codecvt&lt;internT,externT,stateT&gt; is for use when
-converting from one codeset to another, such as from wide characters
-to multibyte characters, between wide character encodings such as
-Unicode and EUC.
-</em></span>
-</p></blockquote></div><p>
-Hmm. So, in some unspecified way, Unicode encodings and
-translations between other character sets should be handled by this
-class.
-</p><div class="blockquote"><blockquote class="blockquote"><p>
-<span class="emphasis"><em>
--2- The stateT argument selects the pair of codesets being mapped between.
-</em></span>
-</p></blockquote></div><p>
-Ah ha! Another clue...
-</p><div class="blockquote"><blockquote class="blockquote"><p>
-<span class="emphasis"><em>
--3- The instantiations required in the Table ??
-(lib.locale.category), namely codecvt&lt;wchar_t,char,mbstate_t&gt; and
-codecvt&lt;char,char,mbstate_t&gt;, convert the implementation-defined
-native character set. codecvt&lt;char,char,mbstate_t&gt; implements a
-degenerate conversion; it does not convert at
-all. codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
-character sets for tiny and wide characters. Instantiations on
-mbstate_t perform conversion between encodings known to the library
-implementor. Other encodings can be converted by specializing on a
-user-defined stateT type. The stateT object can contain any state that
-is useful to communicate to or from the specialized do_convert member.
-</em></span>
-</p></blockquote></div><p>
-At this point, a couple points become clear:
-</p><p>
-One: The standard clearly implies that attempts to add non-required
-(yet useful and widely used) conversions need to do so through the
-third template parameter, stateT.</p><p>
-Two: The required conversions, by specifying mbstate_t as the third
-template parameter, imply an implementation strategy that is mostly
-(or wholly) based on the underlying C library, and the functions
-mcsrtombs and wcsrtombs in particular.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.codecvt.design"></a>Design</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="codecvt.design.wchar_t_size"></a><span class="type">wchar_t</span> Size</h4></div></div></div><p>
- The simple implementation detail of wchar_t's size seems to
- repeatedly confound people. Many systems use a two byte,
- unsigned integral type to represent wide characters, and use an
- internal encoding of Unicode or UCS2. (See AIX, Microsoft NT,
- Java, others.) Other systems, use a four byte, unsigned integral
- type to represent wide characters, and use an internal encoding
- of UCS4. (GNU/Linux systems using glibc, in particular.) The C
- programming language (and thus C++) does not specify a specific
- size for the type wchar_t.
- </p><p>
- Thus, portable C++ code cannot assume a byte size (or endianness) either.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="codecvt.design.unicode"></a>Support for Unicode</h4></div></div></div><p>
- Probably the most frequently asked question about code conversion
- is: "So dudes, what's the deal with Unicode strings?"
- The dude part is optional, but apparently the usefulness of
- Unicode strings is pretty widely appreciated. Sadly, this specific
- encoding (And other useful encodings like UTF8, UCS4, ISO 8859-10,
- etc etc etc) are not mentioned in the C++ standard.
- </p><p>
- A couple of comments:
- </p><p>
- The thought that all one needs to convert between two arbitrary
- codesets is two types and some kind of state argument is
- unfortunate. In particular, encodings may be stateless. The naming
- of the third parameter as stateT is unfortunate, as what is really
- needed is some kind of generalized type that accounts for the
- issues that abstract encodings will need. The minimum information
- that is required includes:
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- Identifiers for each of the codesets involved in the
- conversion. For example, using the iconv family of functions
- from the Single Unix Specification (what used to be called
- X/Open) hosted on the GNU/Linux operating system allows
- bi-directional mapping between far more than the following
- tantalizing possibilities:
- </p><p>
- (An edited list taken from <code class="code">`iconv --list`</code> on a
- Red Hat 6.2/Intel system:
- </p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">
-8859_1, 8859_9, 10646-1:1993, 10646-1:1993/UCS4, ARABIC, ARABIC7,
-ASCII, EUC-CN, EUC-JP, EUC-KR, EUC-TW, GREEK-CCIcode, GREEK, GREEK7-OLD,
-GREEK7, GREEK8, HEBREW, ISO-8859-1, ISO-8859-2, ISO-8859-3,
-ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8,
-ISO-8859-9, ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14,
-ISO-8859-15, ISO-10646, ISO-10646/UCS2, ISO-10646/UCS4,
-ISO-10646/UTF-8, ISO-10646/UTF8, SHIFT-JIS, SHIFT_JIS, UCS-2, UCS-4,
-UCS2, UCS4, UNICODE, UNICODEBIG, UNICODELIcodeLE, US-ASCII, US, UTF-8,
-UTF-16, UTF8, UTF16).
-</pre></blockquote></div><p>
-For iconv-based implementations, string literals for each of the
-encodings (i.e. "UCS-2" and "UTF-8") are necessary,
-although for other,
-non-iconv implementations a table of enumerated values or some other
-mechanism may be required.
-</p></li><li><p>
- Maximum length of the identifying string literal.
-</p></li><li><p>
- Some encodings require explicit endian-ness. As such, some kind
- of endian marker or other byte-order marker will be necessary. See
- "Footnotes for C/C++ developers" in Haible for more information on
- UCS-2/Unicode endian issues. (Summary: big endian seems most likely,
- however implementations, most notably Microsoft, vary.)
-</p></li><li><p>
- Types representing the conversion state, for conversions involving
- the machinery in the "C" library, or the conversion descriptor, for
- conversions using iconv (such as the type iconv_t.) Note that the
- conversion descriptor encodes more information than a simple encoding
- state type.
-</p></li><li><p>
- Conversion descriptors for both directions of encoding. (i.e., both
- UCS-2 to UTF-8 and UTF-8 to UCS-2.)
-</p></li><li><p>
- Something to indicate if the conversion requested if valid.
-</p></li><li><p>
- Something to represent if the conversion descriptors are valid.
-</p></li><li><p>
- Some way to enforce strict type checking on the internal and
- external types. As part of this, the size of the internal and
- external types will need to be known.
-</p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="codecvt.design.issues"></a>Other Issues</h4></div></div></div><p>
-In addition, multi-threaded and multi-locale environments also impact
-the design and requirements for code conversions. In particular, they
-affect the required specialization codecvt&lt;wchar_t, char, mbstate_t&gt;
-when implemented using standard "C" functions.
-</p><p>
-Three problems arise, one big, one of medium importance, and one small.
-</p><p>
-First, the small: mcsrtombs and wcsrtombs may not be multithread-safe
-on all systems required by the GNU tools. For GNU/Linux and glibc,
-this is not an issue.
-</p><p>
-Of medium concern, in the grand scope of things, is that the functions
-used to implement this specialization work on null-terminated
-strings. Buffers, especially file buffers, may not be null-terminated,
-thus giving conversions that end prematurely or are otherwise
-incorrect. Yikes!
-</p><p>
-The last, and fundamental problem, is the assumption of a global
-locale for all the "C" functions referenced above. For something like
-C++ iostreams (where codecvt is explicitly used) the notion of
-multiple locales is fundamental. In practice, most users may not run
-into this limitation. However, as a quality of implementation issue,
-the GNU C++ library would like to offer a solution that allows
-multiple locales and or simultaneous usage with computationally
-correct results. In short, libstdc++ is trying to offer, as an
-option, a high-quality implementation, damn the additional complexity!
-</p><p>
-For the required specialization codecvt&lt;wchar_t, char, mbstate_t&gt; ,
-conversions are made between the internal character set (always UCS4
-on GNU/Linux) and whatever the currently selected locale for the
-LC_CTYPE category implements.
-</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.codecvt.impl"></a>Implementation</h3></div></div></div><p>
-The two required specializations are implemented as follows:
-</p><p>
-<code class="code">
-codecvt&lt;char, char, mbstate_t&gt;
-</code>
-</p><p>
-This is a degenerate (i.e., does nothing) specialization. Implementing
-this was a piece of cake.
-</p><p>
-<code class="code">
-codecvt&lt;char, wchar_t, mbstate_t&gt;
-</code>
-</p><p>
-This specialization, by specifying all the template parameters, pretty
-much ties the hands of implementors. As such, the implementation is
-straightforward, involving mcsrtombs for the conversions between char
-to wchar_t and wcsrtombs for conversions between wchar_t and char.
-</p><p>
-Neither of these two required specializations deals with Unicode
-characters. As such, libstdc++ implements a partial specialization
-of the codecvt class with and iconv wrapper class, encoding_state as the
-third template parameter.
-</p><p>
-This implementation should be standards conformant. First of all, the
-standard explicitly points out that instantiations on the third
-template parameter, stateT, are the proper way to implement
-non-required conversions. Second of all, the standard says (in Chapter
-17) that partial specializations of required classes are a-ok. Third
-of all, the requirements for the stateT type elsewhere in the standard
-(see 21.1.2 traits typedefs) only indicate that this type be copy
-constructible.
-</p><p>
-As such, the type encoding_state is defined as a non-templatized, POD
-type to be used as the third type of a codecvt instantiation. This
-type is just a wrapper class for iconv, and provides an easy interface
-to iconv functionality.
-</p><p>
-There are two constructors for encoding_state:
-</p><p>
-<code class="code">
-encoding_state() : __in_desc(0), __out_desc(0)
-</code>
-</p><p>
-This default constructor sets the internal encoding to some default
-(currently UCS4) and the external encoding to whatever is returned by
-nl_langinfo(CODESET).
-</p><p>
-<code class="code">
-encoding_state(const char* __int, const char* __ext)
-</code>
-</p><p>
-This constructor takes as parameters string literals that indicate the
-desired internal and external encoding. There are no defaults for
-either argument.
-</p><p>
-One of the issues with iconv is that the string literals identifying
-conversions are not standardized. Because of this, the thought of
-mandating and or enforcing some set of pre-determined valid
-identifiers seems iffy: thus, a more practical (and non-migraine
-inducing) strategy was implemented: end-users can specify any string
-(subject to a pre-determined length qualifier, currently 32 bytes) for
-encodings. It is up to the user to make sure that these strings are
-valid on the target system.
-</p><p>
-<code class="code">
-void
-_M_init()
-</code>
-</p><p>
-Strangely enough, this member function attempts to open conversion
-descriptors for a given encoding_state object. If the conversion
-descriptors are not valid, the conversion descriptors returned will
-not be valid and the resulting calls to the codecvt conversion
-functions will return error.
-</p><p>
-<code class="code">
-bool
-_M_good()
-</code>
-</p><p>
-Provides a way to see if the given encoding_state object has been
-properly initialized. If the string literals describing the desired
-internal and external encoding are not valid, initialization will
-fail, and this will return false. If the internal and external
-encodings are valid, but iconv_open could not allocate conversion
-descriptors, this will also return false. Otherwise, the object is
-ready to convert and will return true.
-</p><p>
-<code class="code">
-encoding_state(const encoding_state&amp;)
-</code>
-</p><p>
-As iconv allocates memory and sets up conversion descriptors, the copy
-constructor can only copy the member data pertaining to the internal
-and external code conversions, and not the conversion descriptors
-themselves.
-</p><p>
-Definitions for all the required codecvt member functions are provided
-for this specialization, and usage of codecvt&lt;internal character type,
-external character type, encoding_state&gt; is consistent with other
-codecvt usage.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.codecvt.use"></a>Use</h3></div></div></div><p>A conversions involving string literal.</p><pre class="programlisting">
- typedef codecvt_base::result result;
- typedef unsigned short unicode_t;
- typedef unicode_t int_type;
- typedef char ext_type;
- typedef encoding_state state_type;
- typedef codecvt&lt;int_type, ext_type, state_type&gt; unicode_codecvt;
-
- const ext_type* e_lit = "black pearl jasmine tea";
- int size = strlen(e_lit);
- int_type i_lit_base[24] =
- { 25088, 27648, 24832, 25344, 27392, 8192, 28672, 25856, 24832, 29184,
- 27648, 8192, 27136, 24832, 29440, 27904, 26880, 28160, 25856, 8192, 29696,
- 25856, 24832, 2560
- };
- const int_type* i_lit = i_lit_base;
- const ext_type* efrom_next;
- const int_type* ifrom_next;
- ext_type* e_arr = new ext_type[size + 1];
- ext_type* eto_next;
- int_type* i_arr = new int_type[size + 1];
- int_type* ito_next;
-
- // construct a locale object with the specialized facet.
- locale loc(locale::classic(), new unicode_codecvt);
- // sanity check the constructed locale has the specialized facet.
- VERIFY( has_facet&lt;unicode_codecvt&gt;(loc) );
- const unicode_codecvt&amp; cvt = use_facet&lt;unicode_codecvt&gt;(loc);
- // convert between const char* and unicode strings
- unicode_codecvt::state_type state01("UNICODE", "ISO_8859-1");
- initialize_state(state01);
- result r1 = cvt.in(state01, e_lit, e_lit + size, efrom_next,
- i_arr, i_arr + size, ito_next);
- VERIFY( r1 == codecvt_base::ok );
- VERIFY( !int_traits::compare(i_arr, i_lit, size) );
- VERIFY( efrom_next == e_lit + size );
- VERIFY( ito_next == i_arr + size );
-</pre></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.codecvt.future"></a>Future</h3></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
- a. things that are sketchy, or remain unimplemented:
- do_encoding, max_length and length member functions
- are only weakly implemented. I have no idea how to do
- this correctly, and in a generic manner. Nathan?
-</p></li><li><p>
- b. conversions involving std::string
- </p><div class="itemizedlist"><ul type="circle"><li><p>
- how should operators != and == work for string of
- different/same encoding?
- </p></li><li><p>
- what is equal? A byte by byte comparison or an
- encoding then byte comparison?
- </p></li><li><p>
- conversions between narrow, wide, and unicode strings
- </p></li></ul></div></li><li><p>
- c. conversions involving std::filebuf and std::ostream
-</p><div class="itemizedlist"><ul type="circle"><li><p>
- how to initialize the state object in a
- standards-conformant manner?
- </p></li><li><p>
- how to synchronize the "C" and "C++"
- conversion information?
- </p></li><li><p>
- wchar_t/char internal buffers and conversions between
- internal/external buffers?
- </p></li></ul></div></li></ul></div></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="facet.codecvt.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id415012"></a><p><span class="title"><i>
- The GNU C Library
- </i>. </span><span class="author"><span class="firstname">Roland</span> <span class="surname">McGrath</span>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2007 FSF. </span><span class="pagenums">Chapters 6 Character Set Handling and 7 Locales and Internationalization. </span></p></div><div class="biblioentry"><a id="id514935"></a><p><span class="title"><i>
- Correspondence
- </i>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2002 . </span></p></div><div class="biblioentry"><a id="id416284"></a><p><span class="title"><i>
- ISO/IEC 14882:1998 Programming languages - C++
- </i>. </span><span class="copyright">Copyright © 1998 ISO. </span></p></div><div class="biblioentry"><a id="id416302"></a><p><span class="title"><i>
- ISO/IEC 9899:1999 Programming languages - C
- </i>. </span><span class="copyright">Copyright © 1999 ISO. </span></p></div><div class="biblioentry"><a id="id459727"></a><p><span class="title"><i>
- System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x)
- </i>. </span><span class="copyright">Copyright © 1999
- The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. </span><span class="biblioid">
- <a class="ulink" href="http://www.opennc.org/austin/docreg.html" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id459755"></a><p><span class="title"><i>
- The C++ Programming Language, Special Edition
- </i>. </span><span class="author"><span class="firstname">Bjarne</span> <span class="surname">Stroustrup</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley, Inc.. </span><span class="pagenums">Appendix D. </span><span class="publisher"><span class="publishername">
- Addison Wesley
- . </span></span></p></div><div class="biblioentry"><a id="id430786"></a><p><span class="title"><i>
- Standard C++ IOStreams and Locales
- </i>. </span><span class="subtitle">
- Advanced Programmer's Guide and Reference
- . </span><span class="author"><span class="firstname">Angelika</span> <span class="surname">Langer</span>. </span><span class="author"><span class="firstname">Klaus</span> <span class="surname">Kreft</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley Longman, Inc.. </span><span class="publisher"><span class="publishername">
- Addison Wesley Longman
- . </span></span></p></div><div class="biblioentry"><a id="id407191"></a><p><span class="title"><i>
- A brief description of Normative Addendum 1
- </i>. </span><span class="author"><span class="firstname">Clive</span> <span class="surname">Feather</span>. </span><span class="pagenums">Extended Character Sets. </span><span class="biblioid">
- <a class="ulink" href="http://www.lysator.liu.se/c/na1.html" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id394112"></a><p><span class="title"><i>
- The Unicode HOWTO
- </i>. </span><span class="author"><span class="firstname">Bruno</span> <span class="surname">Haible</span>. </span><span class="biblioid">
- <a class="ulink" href="ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id394140"></a><p><span class="title"><i>
- UTF-8 and Unicode FAQ for Unix/Linux
- </i>. </span><span class="author"><span class="firstname">Markus</span> <span class="surname">Khun</span>. </span><span class="biblioid">
- <a class="ulink" href="http://www.cl.cam.ac.uk/~mgk25/unicode.html" target="_top">
- </a>
- . </span></p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="facets.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="facets.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="messages.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 15. Facets aka Categories </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> messages</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/complex.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/complex.html
deleted file mode 100644
index 2bcdc1792..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/complex.html
+++ /dev/null
@@ -1,25 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 21. Complex</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="numerics.html" title="Part X.  Numerics" /><link rel="prev" href="numerics.html" title="Part X.  Numerics" /><link rel="next" href="generalized_numeric_operations.html" title="Chapter 22. Generalized Operations" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 21. Complex</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="numerics.html">Prev</a> </td><th width="60%" align="center">Part X. 
- Numerics
-
-</th><td width="20%" align="right"> <a accesskey="n" href="generalized_numeric_operations.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.numerics.complex"></a>Chapter 21. Complex</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="complex.html#numerics.complex.processing">complex Processing</a></span></dt></dl></div><p>
- </p><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="numerics.complex.processing"></a>complex Processing</h2></div></div></div><p>
- </p><p>Using <code class="code">complex&lt;&gt;</code> becomes even more comple- er, sorry,
- <span class="emphasis"><em>complicated</em></span>, with the not-quite-gratuitously-incompatible
- addition of complex types to the C language. David Tribble has
- compiled a list of C++98 and C99 conflict points; his description of
- C's new type versus those of C++ and how to get them playing together
- nicely is
-<a class="ulink" href="http://david.tribble.com/text/cdiffs.htm#C99-complex" target="_top">here</a>.
- </p><p><code class="code">complex&lt;&gt;</code> is intended to be instantiated with a
- floating-point type. As long as you meet that and some other basic
- requirements, then the resulting instantiation has all of the usual
- math operators defined, as well as definitions of <code class="code">op&lt;&lt;</code>
- and <code class="code">op&gt;&gt;</code> that work with iostreams: <code class="code">op&lt;&lt;</code>
- prints <code class="code">(u,v)</code> and <code class="code">op&gt;&gt;</code> can read <code class="code">u</code>,
- <code class="code">(u)</code>, and <code class="code">(u,v)</code>.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="numerics.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="numerics.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="generalized_numeric_operations.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part X. 
- Numerics
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 22. Generalized Operations</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/configure.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/configure.html
deleted file mode 100644
index 9aadf235e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/configure.html
+++ /dev/null
@@ -1,201 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Configure</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; configure&#10; , &#10; options&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="setup.html" title="Chapter 2. Setup" /><link rel="prev" href="setup.html" title="Chapter 2. Setup" /><link rel="next" href="make.html" title="Make" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Configure</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="setup.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Setup</th><td width="20%" align="right"> <a accesskey="n" href="make.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.setup.configure"></a>Configure</h2></div></div></div><p>
- When configuring libstdc++, you'll have to configure the entire
- <span class="emphasis"><em>gccsrcdir</em></span> directory. Consider using the
- toplevel gcc configuration option
- <code class="literal">--enable-languages=c++</code>, which saves time by only
- building the C++ toolchain.
-</p><p>
- Here are all of the configure options specific to libstdc++. Keep
- in mind that
-
- <a class="ulink" href="http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_131.html#SEC131" target="_top">they
- all have opposite forms as well</a> (enable/disable and
- with/without). The defaults are for the <span class="emphasis"><em>current
- development sources</em></span>, which may be different than those
- for released versions.
-</p><p>The canonical way to find out the configure options that are
- available for a given set of libstdc++ sources is to go to the
- source directory and then type:<span class="command"><strong>./configure --help</strong></span>.
-</p><div class="variablelist"><dl><dt><span class="term"><code class="code">--enable-multilib</code>[default]</span></dt><dd><p>This is part of the generic multilib support for building cross
- compilers. As such, targets like "powerpc-elf" will have
- libstdc++ built many different ways: "-msoft-float"
- and not, etc. A different libstdc++ will be built for each of
- the different multilib versions. This option is on by default.
- </p></dd><dt><span class="term"><code class="code">--enable-sjlj-exceptions</code></span></dt><dd><p>Forces old, set-jump/long-jump exception handling model. If
- at all possible, the new, frame unwinding exception handling routines
- should be used instead, as they significantly reduce both
- runtime memory usage and executable size. This option can
- change the library ABI.
- </p></dd><dt><span class="term"><code class="code">--enable-version-specific-runtime-libs</code></span></dt><dd><p>Specify that run-time libraries should be installed in the
- compiler-specific subdirectory (i.e.,
- <code class="code">${libdir}/gcc-lib/${target_alias}/${gcc_version}</code>)
- instead of <code class="code">${libdir}</code>. This option is useful if you
- intend to use several versions of gcc in parallel. In addition,
- libstdc++'s include files will be installed in
- <code class="code">${libdir}/gcc-lib/${target_alias}/${gcc_version}/include/g++</code>,
- unless you also specify
- <code class="literal">--with-gxx-include-dir=<code class="filename">dirname</code></code> during configuration.
- </p></dd><dt><span class="term"><code class="code">--with-gxx-include-dir=&lt;include-files dir&gt;</code></span></dt><dd><p>Adds support for named libstdc++ include directory. For instance,
- the following puts all the libstdc++ headers into a directory
- called "2.97-20001008" instead of the usual
- "c++/(version)".
- </p><pre class="programlisting">
- --with-gxx-include-dir=/foo/H-x86-gcc-3-c-gxx-inc/include/2.97-20001008</pre></dd><dt><span class="term"><code class="code">--enable-cstdio</code></span></dt><dd><p>This is an abbreviated form of <code class="code">'--enable-cstdio=stdio'</code>
- (described next). This option can change the library ABI.
- </p></dd><dt><span class="term"><code class="code">--enable-cstdio=OPTION</code></span></dt><dd><p>Select a target-specific I/O package. At the moment, the only
- choice is to use 'stdio', a generic "C" abstraction.
- The default is 'stdio'.
- </p></dd><dt><span class="term"><code class="code">--enable-clocale</code></span></dt><dd><p>This is an abbreviated form of <code class="code">'--enable-clocale=generic'</code>
- (described next). This option can change the library ABI.
- </p></dd><dt><span class="term"><code class="code">--enable-clocale=OPTION</code></span></dt><dd><p>Select a target-specific underlying locale package. The
- choices are 'ieee_1003.1-2001' to specify an X/Open, Standard Unix
- (IEEE Std. 1003.1-2001) model based on langinfo/iconv/catgets,
- 'gnu' to specify a model based on functionality from the GNU C
- library (langinfo/iconv/gettext) (from <a class="ulink" href="http://sources.redhat.com/glibc/" target="_top">glibc</a>, the GNU C
- library), or 'generic' to use a generic "C"
- abstraction which consists of "C" locale info.
- </p><p>As part of the configuration process, the "C" library is
- probed both for sufficient vintage, and installed locale
- data. If either of these elements are not present, the C++
- locale model default to 'generic.' On glibc-based systems of
- version 2.2.5 and above with installed locale files, 'gnu' is
- automatically selected.
- </p></dd><dt><span class="term"><code class="code">--enable-libstdcxx-allocator</code></span></dt><dd><p>This is an abbreviated form of
- <code class="code">'--enable-libstdcxx-allocator=auto'</code> (described
- next). This option can change the library ABI.
- </p></dd><dt><span class="term"><code class="code">--enable-libstdcxx-allocator=OPTION </code></span></dt><dd><p>Select a target-specific underlying std::allocator. The
- choices are 'new' to specify a wrapper for new, 'malloc' to
- specify a wrapper for malloc, 'mt' for a fixed power of two allocator,
- 'pool' for the SGI pooled allocator or 'bitmap' for a bitmap allocator.
- This option can change the library ABI. See this page for more information on allocator
- <a class="link" href="memory.html#allocator.ext" title="Extension Allocators">extensions</a>
- </p></dd><dt><span class="term"><code class="code">--enable-cheaders=OPTION</code></span></dt><dd><p>This allows the user to define the approach taken for C header
- compatibility with C++. Options are c, c_std, and c_global.
- These correspond to the source directory's include/c,
- include/c_std, and include/c_global, and may also include
- include/c_compatibility. The default is c_global.
- </p></dd><dt><span class="term"><code class="code">--enable-threads</code></span></dt><dd><p>This is an abbreviated form of <code class="code">'--enable-threads=yes'</code>
- (described next). This option can change the library ABI.
- </p></dd><dt><span class="term"><code class="code">--enable-threads=OPTION</code></span></dt><dd><p>Select a threading library. A full description is given in the
- general <a class="ulink" href="http://gcc.gnu.org/install/configure.html" target="_top">compiler
- configuration instructions</a>.
- </p></dd><dt><span class="term"><code class="code">--enable-libstdcxx-debug</code></span></dt><dd><p>Build separate debug libraries in addition to what is normally built.
- By default, the debug libraries are compiled with
- <code class="code"> CXXFLAGS='-g3 -O0 -fno-inline'</code>
- , are installed in <code class="code">${libdir}/debug</code>, and have the
- same names and versioning information as the non-debug
- libraries. This option is off by default.
- </p><p>Note this make command, executed in
- the build directory, will do much the same thing, without the
- configuration difference and without building everything twice:
- <code class="code">make CXXFLAGS='-g3 -O0 -fno-inline' all</code>
- </p></dd><dt><span class="term"><code class="code">--enable-libstdcxx-debug-flags=FLAGS</code></span></dt><dd><p>This option is only valid when <code class="code"> --enable-debug </code>
- is also specified, and applies to the debug builds only. With
- this option, you can pass a specific string of flags to the
- compiler to use when building the debug versions of libstdc++.
- FLAGS is a quoted string of options, like
- </p><pre class="programlisting">
- --enable-libstdcxx-debug-flags='-g3 -O1 -fno-inline'</pre></dd><dt><span class="term"><code class="code">--enable-cxx-flags=FLAGS</code></span></dt><dd><p>With this option, you can pass a string of -f (functionality)
- flags to the compiler to use when building libstdc++. This
- option can change the library ABI. FLAGS is a quoted string of
- options, like
- </p><pre class="programlisting">
- --enable-cxx-flags='-fvtable-gc -fomit-frame-pointer -ansi'</pre><p>
- Note that the flags don't necessarily have to all be -f flags,
- as shown, but usually those are the ones that will make sense
- for experimentation and configure-time overriding.
- </p><p>The advantage of --enable-cxx-flags over setting CXXFLAGS in
- the 'make' environment is that, if files are automatically
- rebuilt, the same flags will be used when compiling those files
- as well, so that everything matches.
- </p><p>Fun flags to try might include combinations of
- </p><pre class="programlisting">
- -fstrict-aliasing
- -fno-exceptions
- -ffunction-sections
- -fvtable-gc</pre><p>and opposite forms (-fno-) of the same. Tell us (the libstdc++
- mailing list) if you discover more!
- </p></dd><dt><span class="term"><code class="code">--enable-c99</code></span></dt><dd><p>The "long long" type was introduced in C99, along
- with many other functions for wide characters, and math
- classification macros, etc. If enabled, all C99 functions not
- specified by the C++ standard will be put into <code class="code">namespace
- __gnu_cxx</code>, and then all these names will
- be injected into namespace std, so that C99 functions can be
- used "as if" they were in the C++ standard (as they
- will eventually be in some future revision of the standard,
- without a doubt). By default, C99 support is on, assuming the
- configure probes find all the necessary functions and bits
- necessary. This option can change the library ABI.
- </p></dd><dt><span class="term"><code class="code">--enable-wchar_t</code>[default]</span></dt><dd><p>Template specializations for the "wchar_t" type are
- required for wide character conversion support. Disabling
- wide character specializations may be expedient for initial
- porting efforts, but builds only a subset of what is required by
- ISO, and is not recommended. By default, this option is on.
- This option can change the library ABI.
- </p></dd><dt><span class="term"><code class="code">--enable-long-long </code></span></dt><dd><p>The "long long" type was introduced in C99. It is
- provided as a GNU extension to C++98 in g++. This flag builds
- support for "long long" into the library (specialized
- templates and the like for iostreams). This option is on by default:
- if enabled, users will have to either use the new-style "C"
- headers by default (i.e., &lt;cmath&gt; not &lt;math.h&gt;)
- or add appropriate compile-time flags to all compile lines to
- allow "C" visibility of this feature (on GNU/Linux,
- the flag is -D_ISOC99_SOURCE, which is added automatically via
- CPLUSPLUS_CPP_SPEC's addition of _GNU_SOURCE).
- This option can change the library ABI.
- </p></dd><dt><span class="term"><code class="code">--enable-fully-dynamic-string</code></span></dt><dd><p>This option enables a special version of basic_string avoiding
- the optimization that allocates empty objects in static memory.
- Mostly useful together with shared memory allocators, see PR
- libstdc++/16612 for details.
- </p></dd><dt><span class="term"><code class="code">--enable-concept-checks</code></span></dt><dd><p>This turns on additional compile-time checks for instantiated
- library templates, in the form of specialized templates,
- <a class="link" href="bk01pt03ch08.html" title="Chapter 8. Concept Checking">described here</a>. They
- can help users discover when they break the rules of the STL, before
- their programs run.
- </p></dd><dt><span class="term"><code class="code">--enable-symvers[=style]</code></span></dt><dd><p>In 3.1 and later, tries to turn on symbol versioning in the
- shared library (if a shared library has been
- requested). Values for 'style' that are currently supported
- are 'gnu', 'gnu-versioned-namespace', 'darwin', and
- 'darwin-export'. Both gnu- options require that a recent
- version of the GNU linker be in use. Both darwin options are
- equivalent. With no style given, the configure script will try
- to guess correct defaults for the host system, probe to see if
- additional requirements are necessary and present for
- activation, and if so, will turn symbol versioning on. This
- option can change the library ABI.
- </p></dd><dt><span class="term"><code class="code">--enable-visibility</code></span></dt><dd><p> In 4.2 and later, enables or disables visibility attributes.
- If enabled (as by default), and the compiler seems capable of
- passing the simple sanity checks thrown at it, adjusts items
- in namespace std, namespace std::tr1, and namespace __gnu_cxx
- so that -fvisibility options work.
- </p></dd><dt><span class="term"><code class="code">--enable-libstdcxx-pch</code></span></dt><dd><p>In 3.4 and later, tries to turn on the generation of
- stdc++.h.gch, a pre-compiled file including all the standard
- C++ includes. If enabled (as by default), and the compiler
- seems capable of passing the simple sanity checks thrown at
- it, try to build stdc++.h.gch as part of the make process.
- In addition, this generated file is used later on (by appending <code class="code">
- --include bits/stdc++.h </code> to CXXFLAGS) when running the
- testsuite.
- </p></dd><dt><span class="term"><code class="code">--disable-hosted-libstdcxx</code></span></dt><dd><p>
- By default, a complete <span class="emphasis"><em>hosted</em></span> C++ library is
- built. The C++ Standard also describes a
- <span class="emphasis"><em>freestanding</em></span> environment, in which only a
- minimal set of headers are provided. This option builds such an
- environment.
- </p></dd><dt><span class="term"><code class="code">--enable-clock-gettime</code></span></dt><dd><p>This is an abbreviated form of
- <code class="code">'--enable-clock-gettime=yes'</code>(described next).
- </p></dd><dt><span class="term"><code class="code">--enable-libstdcxx-time=OPTION</code></span></dt><dd><p>Enables link-type checks for the availability of the
- clock_gettime clocks, used in the implementation of [time.clock],
- and of the nanosleep and sched_yield functions, used in the
- implementation of [thread.thread.this] of the current C++0x draft.
- The choice OPTION=yes checks for the availability of the facilities
- in libc and libposix4. In case of need the latter is also linked
- to libstdc++ as part of the build process. OPTION=rt also searches
- (and, in case, links) librt. Note that the latter is not always
- desirable because, in glibc, for example, in turn it triggers the
- linking of libpthread too, which activates locking, a large overhead
- for single-thread programs. OPTION=no skips the tests completely.
- The default is OPTION=no.
- </p></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="setup.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="setup.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="make.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 2. Setup </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Make</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/containers.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/containers.html
deleted file mode 100644
index f035c3ca6..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/containers.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part VII.  Containers</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="messages.html" title="messages" /><link rel="next" href="sequences.html" title="Chapter 16. Sequences" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part VII. 
- Containers
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="messages.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="sequences.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.containers"></a>Part VII. 
- Containers
- <a id="id410385" class="indexterm"></a>
-</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="sequences.html">16. Sequences</a></span></dt><dd><dl><dt><span class="sect1"><a href="sequences.html#containers.sequences.list">list</a></span></dt><dd><dl><dt><span class="sect2"><a href="sequences.html#sequences.list.size">list::size() is O(n)</a></span></dt></dl></dd><dt><span class="sect1"><a href="vector.html">vector</a></span></dt><dd><dl><dt><span class="sect2"><a href="vector.html#sequences.vector.management">Space Overhead Management</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="associative.html">17. Associative</a></span></dt><dd><dl><dt><span class="sect1"><a href="associative.html#containers.associative.insert_hints">Insertion Hints</a></span></dt><dt><span class="sect1"><a href="bitset.html">bitset</a></span></dt><dd><dl><dt><span class="sect2"><a href="bitset.html#associative.bitset.size_variable">Size Variable</a></span></dt><dt><span class="sect2"><a href="bitset.html#associative.bitset.type_string">Type String</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="containers_and_c.html">18. Interacting with C</a></span></dt><dd><dl><dt><span class="sect1"><a href="containers_and_c.html#containers.c.vs_array">Containers vs. Arrays</a></span></dt></dl></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="messages.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="sequences.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">messages </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 16. Sequences</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/containers_and_c.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/containers_and_c.html
deleted file mode 100644
index 512f7a2c5..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/containers_and_c.html
+++ /dev/null
@@ -1,66 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 18. Interacting with C</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="containers.html" title="Part VII.  Containers" /><link rel="prev" href="bitset.html" title="bitset" /><link rel="next" href="iterators.html" title="Part VIII.  Iterators" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 18. Interacting with C</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bitset.html">Prev</a> </td><th width="60%" align="center">Part VII. 
- Containers
-
-</th><td width="20%" align="right"> <a accesskey="n" href="iterators.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.containers.c"></a>Chapter 18. Interacting with C</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="containers_and_c.html#containers.c.vs_array">Containers vs. Arrays</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="containers.c.vs_array"></a>Containers vs. Arrays</h2></div></div></div><p>
- You're writing some code and can't decide whether to use builtin
- arrays or some kind of container. There are compelling reasons
- to use one of the container classes, but you're afraid that
- you'll eventually run into difficulties, change everything back
- to arrays, and then have to change all the code that uses those
- data types to keep up with the change.
- </p><p>
- If your code makes use of the standard algorithms, this isn't as
- scary as it sounds. The algorithms don't know, nor care, about
- the kind of “<span class="quote">container</span>” on which they work, since
- the algorithms are only given endpoints to work with. For the
- container classes, these are iterators (usually
- <code class="code">begin()</code> and <code class="code">end()</code>, but not always).
- For builtin arrays, these are the address of the first element
- and the <a class="ulink" href="../24_iterators/howto.html#2" target="_top">past-the-end</a> element.
- </p><p>
- Some very simple wrapper functions can hide all of that from the
- rest of the code. For example, a pair of functions called
- <code class="code">beginof</code> can be written, one that takes an array,
- another that takes a vector. The first returns a pointer to the
- first element, and the second returns the vector's
- <code class="code">begin()</code> iterator.
- </p><p>
- The functions should be made template functions, and should also
- be declared inline. As pointed out in the comments in the code
- below, this can lead to <code class="code">beginof</code> being optimized out
- of existence, so you pay absolutely nothing in terms of increased
- code size or execution time.
- </p><p>
- The result is that if all your algorithm calls look like
- </p><pre class="programlisting">
- std::transform(beginof(foo), endof(foo), beginof(foo), SomeFunction);
- </pre><p>
- then the type of foo can change from an array of ints to a vector
- of ints to a deque of ints and back again, without ever changing
- any client code.
- </p><p>
- This author has a collection of such functions, called
- “<span class="quote">*of</span>” because they all extend the builtin
- “<span class="quote">sizeof</span>”. It started with some Usenet discussions
- on a transparent way to find the length of an array. A
- simplified and much-reduced version for easier reading is <a class="ulink" href="wrappers_h.txt" target="_top">given here</a>.
- </p><p>
- Astute readers will notice two things at once: first, that the
- container class is still a <code class="code">vector&lt;T&gt;</code> instead
- of a more general <code class="code">Container&lt;T&gt;</code>. This would
- mean that three functions for <code class="code">deque</code> would have to be
- added, another three for <code class="code">list</code>, and so on. This is
- due to problems with getting template resolution correct; I find
- it easier just to give the extra three lines and avoid confusion.
- </p><p>
- Second, the line
- </p><pre class="programlisting">
- inline unsigned int lengthof (T (&amp;)[sz]) { return sz; }
- </pre><p>
- looks just weird! Hint: unused parameters can be left nameless.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bitset.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="containers.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="iterators.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">bitset </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part VIII. 
- Iterators
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/debug.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/debug.html
deleted file mode 100644
index 1dd28689f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/debug.html
+++ /dev/null
@@ -1,152 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Debugging Support</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; C++&#10; , &#10; debug&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="using_exceptions.html" title="Exceptions" /><link rel="next" href="support.html" title="Part II.  Support" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Debugging Support</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="using_exceptions.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="support.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.debug"></a>Debugging Support</h2></div></div></div><p>
- There are numerous things that can be done to improve the ease with
- which C++ binaries are debugged when using the GNU tool chain. Here
- are some of them.
-</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="debug.compiler"></a>Using <span class="command"><strong>g++</strong></span></h3></div></div></div><p>
- Compiler flags determine how debug information is transmitted
- between compilation and debug or analysis tools.
- </p><p>
- The default optimizations and debug flags for a libstdc++ build
- are <code class="code">-g -O2</code>. However, both debug and optimization
- flags can be varied to change debugging characteristics. For
- instance, turning off all optimization via the <code class="code">-g -O0
- -fno-inline</code> flags will disable inlining and optimizations,
- and add debugging information, so that stepping through all functions,
- (including inlined constructors and destructors) is possible. In
- addition, <code class="code">-fno-eliminate-unused-debug-types</code> can be
- used when additional debug information, such as nested class info,
- is desired.
-</p><p>
- Or, the debug format that the compiler and debugger use to
- communicate information about source constructs can be changed via
- <code class="code">-gdwarf-2</code> or <code class="code">-gstabs</code> flags: some debugging
- formats permit more expressive type and scope information to be
- shown in gdb. Expressiveness can be enhanced by flags like
- <code class="code">-g3</code>. The default debug information for a particular
- platform can be identified via the value set by the
- PREFERRED_DEBUGGING_TYPE macro in the gcc sources.
-</p><p>
- Many other options are available: please see <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#Debugging%20Options" target="_top">"Options
- for Debugging Your Program"</a> in Using the GNU Compiler
- Collection (GCC) for a complete list.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="debug.req"></a>Debug Versions of Library Binary Files</h3></div></div></div><p>
- If you would like debug symbols in libstdc++, there are two ways to
- build libstdc++ with debug flags. The first is to run make from the
- toplevel in a freshly-configured tree with
-</p><pre class="programlisting">
- --enable-libstdcxx-debug
-</pre><p>and perhaps</p><pre class="programlisting">
- --enable-libstdcxx-debug-flags='...'
-</pre><p>
- to create a separate debug build. Both the normal build and the
- debug build will persist, without having to specify
- <code class="code">CXXFLAGS</code>, and the debug library will be installed in a
- separate directory tree, in <code class="code">(prefix)/lib/debug</code>. For
- more information, look at the <a class="link" href="configure.html" title="Configure">configuration</a> section.
-</p><p>
- A second approach is to use the configuration flags
-</p><pre class="programlisting">
- make CXXFLAGS='-g3 -fno-inline -O0' all
-</pre><p>
- This quick and dirty approach is often sufficient for quick
- debugging tasks, when you cannot or don't want to recompile your
- application to use the <a class="link" href="debug_mode.html" title="Chapter 30. Debug Mode">debug mode</a>.</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="debug.memory"></a>Memory Leak Hunting</h3></div></div></div><p>
- There are various third party memory tracing and debug utilities
- that can be used to provide detailed memory allocation information
- about C++ code. An exhaustive list of tools is not going to be
- attempted, but includes <code class="code">mtrace</code>, <code class="code">valgrind</code>,
- <code class="code">mudflap</code>, and the non-free commercial product
- <code class="code">purify</code>. In addition, <code class="code">libcwd</code> has a
- replacement for the global new and delete operators that can track
- memory allocation and deallocation and provide useful memory
- statistics.
-</p><p>
- Regardless of the memory debugging tool being used, there is one
- thing of great importance to keep in mind when debugging C++ code
- that uses <code class="code">new</code> and <code class="code">delete</code>: there are
- different kinds of allocation schemes that can be used by <code class="code">
- std::allocator </code>. For implementation details, see the <a class="link" href="ext_allocators.html#manual.ext.allocator.mt" title="mt_allocator">mt allocator</a> documentation and
- look specifically for <code class="code">GLIBCXX_FORCE_NEW</code>.
-</p><p>
- In a nutshell, the default allocator used by <code class="code">
- std::allocator</code> is a high-performance pool allocator, and can
- give the mistaken impression that in a suspect executable, memory is
- being leaked, when in reality the memory "leak" is a pool being used
- by the library's allocator and is reclaimed after program
- termination.
-</p><p>
- For valgrind, there are some specific items to keep in mind. First
- of all, use a version of valgrind that will work with current GNU
- C++ tools: the first that can do this is valgrind 1.0.4, but later
- versions should work at least as well. Second of all, use a
- completely unoptimized build to avoid confusing valgrind. Third, use
- GLIBCXX_FORCE_NEW to keep extraneous pool allocation noise from
- cluttering debug information.
-</p><p>
- Fourth, it may be necessary to force deallocation in other libraries
- as well, namely the "C" library. On linux, this can be accomplished
- with the appropriate use of the <code class="code">__cxa_atexit</code> or
- <code class="code">atexit</code> functions.
-</p><pre class="programlisting">
- #include &lt;cstdlib&gt;
-
- extern "C" void __libc_freeres(void);
-
- void do_something() { }
-
- int main()
- {
- atexit(__libc_freeres);
- do_something();
- return 0;
- }
-</pre><p>or, using <code class="code">__cxa_atexit</code>:</p><pre class="programlisting">
- extern "C" void __libc_freeres(void);
- extern "C" int __cxa_atexit(void (*func) (void *), void *arg, void *d);
-
- void do_something() { }
-
- int main()
- {
- extern void* __dso_handle __attribute__ ((__weak__));
- __cxa_atexit((void (*) (void *)) __libc_freeres, NULL,
- &amp;__dso_handle ? __dso_handle : NULL);
- do_test();
- return 0;
- }
-</pre><p>
- Suggested valgrind flags, given the suggestions above about setting
- up the runtime environment, library, and test file, might be:
-</p><pre class="programlisting">
- valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes a.out
-</pre></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="debug.gdb"></a>Using <span class="command"><strong>gdb</strong></span></h3></div></div></div><p>
- </p><p>
- Many options are available for gdb itself: please see <a class="ulink" href="http://sources.redhat.com/gdb/current/onlinedocs/gdb_13.html#SEC125" target="_top">
- "GDB features for C++" </a> in the gdb documentation. Also
- recommended: the other parts of this manual.
-</p><p>
- These settings can either be switched on in at the gdb command line,
- or put into a .gdbint file to establish default debugging
- characteristics, like so:
-</p><pre class="programlisting">
- set print pretty on
- set print object on
- set print static-members on
- set print vtbl on
- set print demangle on
- set demangle-style gnu-v3
-</pre></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="debug.exceptions"></a>Tracking uncaught exceptions</h3></div></div></div><p>
- The <a class="link" href="verbose_termination.html" title="Verbose Terminate Handler">verbose
- termination handler</a> gives information about uncaught
- exceptions which are killing the program. It is described in the
- linked-to page.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="debug.debug_mode"></a>Debug Mode</h3></div></div></div><p> The <a class="link" href="debug_mode.html" title="Chapter 30. Debug Mode">Debug Mode</a>
- has compile and run-time checks for many containers.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="debug.compile_time_checks"></a>Compile Time Checking</h3></div></div></div><p> The <a class="link" href="ext_compile_checks.html" title="Chapter 29. Compile Time Checks">Compile-Time
- Checks</a> Extension has compile-time checks for many algorithms.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="using_exceptions.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="support.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Exceptions </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part II. 
- Support
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/debug_mode.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/debug_mode.html
deleted file mode 100644
index e83c51e74..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/debug_mode.html
+++ /dev/null
@@ -1,37 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 30. Debug Mode</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; debug&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="ext_compile_checks.html" title="Chapter 29. Compile Time Checks" /><link rel="next" href="bk01pt12ch30s02.html" title="Semantics" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 30. Debug Mode</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ext_compile_checks.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch30s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.debug_mode"></a>Chapter 30. Debug Mode</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="debug_mode.html#manual.ext.debug_mode.intro">Intro</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch30s02.html">Semantics</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch30s03.html">Using</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch30s03.html#debug_mode.using.mode">Using the Debug Mode</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch30s03.html#debug_mode.using.specific">Using a Specific Debug Container</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch30s04.html">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch30s04.html#manual.ext.debug_mode.design.goals">Goals</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch30s04.html#manual.ext.debug_mode.design.methods">Methods</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch30s04.html#manual.ext.debug_mode.design.other">Other Implementations</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.debug_mode.intro"></a>Intro</h2></div></div></div><p>
- By default, libstdc++ is built with efficiency in mind, and
- therefore performs little or no error checking that is not
- required by the C++ standard. This means that programs that
- incorrectly use the C++ standard library will exhibit behavior
- that is not portable and may not even be predictable, because they
- tread into implementation-specific or undefined behavior. To
- detect some of these errors before they can become problematic,
- libstdc++ offers a debug mode that provides additional checking of
- library facilities, and will report errors in the use of libstdc++
- as soon as they can be detected by emitting a description of the
- problem to standard error and aborting the program. This debug
- mode is available with GCC 3.4.0 and later versions.
- </p><p>
- The libstdc++ debug mode performs checking for many areas of the
- C++ standard, but the focus is on checking interactions among
- standard iterators, containers, and algorithms, including:
- </p><div class="itemizedlist"><ul type="disc"><li><p><span class="emphasis"><em>Safe iterators</em></span>: Iterators keep track of the
- container whose elements they reference, so errors such as
- incrementing a past-the-end iterator or dereferencing an iterator
- that points to a container that has been destructed are diagnosed
- immediately.</p></li><li><p><span class="emphasis"><em>Algorithm preconditions</em></span>: Algorithms attempt to
- validate their input parameters to detect errors as early as
- possible. For instance, the <code class="code">set_intersection</code>
- algorithm requires that its iterator
- parameters <code class="code">first1</code> and <code class="code">last1</code> form a valid
- iterator range, and that the sequence
- [<code class="code">first1</code>, <code class="code">last1</code>) is sorted according to
- the same predicate that was passed
- to <code class="code">set_intersection</code>; the libstdc++ debug mode will
- detect an error if the sequence is not sorted or was sorted by a
- different predicate.</p></li></ul></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ext_compile_checks.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch30s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 29. Compile Time Checks </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Semantics</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/diagnostics.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/diagnostics.html
deleted file mode 100644
index 4827d234e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/diagnostics.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part III.  Diagnostics</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="verbose_termination.html" title="Verbose Terminate Handler" /><link rel="next" href="exceptions.html" title="Chapter 7. Exceptions" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part III. 
- Diagnostics
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="verbose_termination.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="exceptions.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.diagnostics"></a>Part III. 
- Diagnostics
- <a id="id490226" class="indexterm"></a>
-</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="exceptions.html">7. Exceptions</a></span></dt><dd><dl><dt><span class="sect1"><a href="exceptions.html#manual.diagnostics.exceptions.hierarchy">Exception Classes</a></span></dt><dt><span class="sect1"><a href="bk01pt03ch07s02.html">Adding Data to Exceptions</a></span></dt><dt><span class="sect1"><a href="bk01pt03ch07s03.html">Cancellation</a></span></dt></dl></dd><dt><span class="chapter"><a href="bk01pt03ch08.html">8. Concept Checking</a></span></dt></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="verbose_termination.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="exceptions.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Verbose Terminate Handler </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 7. Exceptions</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/documentation_style.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/documentation_style.html
deleted file mode 100644
index 6ea25c8fe..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/documentation_style.html
+++ /dev/null
@@ -1,230 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Documentation Style</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_contributing.html" title="Appendix A.  Contributing" /><link rel="prev" href="source_code_style.html" title="Coding Style" /><link rel="next" href="source_design_notes.html" title="Design Notes" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Documentation Style</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="source_code_style.html">Prev</a> </td><th width="60%" align="center">Appendix A. 
- Contributing
-
-</th><td width="20%" align="right"> <a accesskey="n" href="source_design_notes.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contrib.doc_style"></a>Documentation Style</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="doc_style.doxygen"></a>Doxygen</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="doxygen.prereq"></a>Prerequisites</h4></div></div></div><p>
- Prerequisite tools are Bash 2.x,
- <a class="ulink" href="http://www.doxygen.org/" target="_top">Doxygen</a>, and
- the <a class="ulink" href="http://www.gnu.org/software/coreutils/" target="_top">GNU
- coreutils</a>. (GNU versions of find, xargs, and possibly
- sed and grep are used, just because the GNU versions make
- things very easy.)
- </p><p>
- To generate the pretty pictures and hierarchy
- graphs, the
- <a class="ulink" href="http://www.research.att.com/sw/tools/graphviz/download.html" target="_top">Graphviz</a>
- package will need to be installed.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="doxygen.rules"></a>Generating the Doxygen Files</h4></div></div></div><p>
- The following Makefile rules run Doxygen to generate HTML
- docs, XML docs, and the man pages.
- </p><p>
- </p><pre class="screen"><strong class="userinput"><code>make doc-html-doxygen</code></strong></pre><p>
- </p><p>
- </p><pre class="screen"><strong class="userinput"><code>make doc-xml-doxygen</code></strong></pre><p>
- </p><p>
- </p><pre class="screen"><strong class="userinput"><code>make doc-man-doxygen</code></strong></pre><p>
- </p><p>
- Careful observers will see that the Makefile rules simply call
- a script from the source tree, <code class="filename">run_doxygen</code>, which
- does the actual work of running Doxygen and then (most
- importantly) massaging the output files. If for some reason
- you prefer to not go through the Makefile, you can call this
- script directly. (Start by passing <code class="literal">--help</code>.)
- </p><p>
- If you wish to tweak the Doxygen settings, do so by editing
- <code class="filename">doc/doxygen/user.cfg.in</code>. Notes to fellow
- library hackers are written in triple-# comments.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="doxygen.markup"></a>Markup</h4></div></div></div><p>
- In general, libstdc++ files should be formatted according to
- the rules found in the
- <a class="link" href="source_code_style.html" title="Coding Style">Coding Standard</a>. Before
- any doxygen-specific formatting tweaks are made, please try to
- make sure that the initial formatting is sound.
- </p><p>
- Adding Doxygen markup to a file (informally called
- “<span class="quote">doxygenating</span>”) is very simple. The Doxygen manual can be
- found
- <a class="ulink" href="http://www.stack.nl/~dimitri/doxygen/download.html#latestman" target="_top">here</a>.
- We try to use a very-recent version of Doxygen.
- </p><p>
- For classes, use
- <code class="classname">deque</code>/<code class="classname">vector</code>/<code class="classname">list</code>
- and <code class="classname">std::pair</code> as examples. For
- functions, see their member functions, and the free functions
- in <code class="filename">stl_algobase.h</code>. Member functions of
- other container-like types should read similarly to these
- member functions.
- </p><p>
- These points accompany the first list in section 3.1 of the
- Doxygen manual:
- </p><div class="orderedlist"><ol type="1"><li><p>Use the Javadoc style...</p></li><li><p>
- ...not the Qt style. The intermediate *'s are preferred.
- </p></li><li><p>
- Use the triple-slash style only for one-line comments (the
- “<span class="quote">brief</span>” mode). Very recent versions of Doxygen permit
- full-mode comments in triple-slash blocks, but the
- formatting still comes out wonky.
- </p></li><li><p>
- This is disgusting. Don't do this.
- </p></li></ol></div><p>
- Use the @-style of commands, not the !-style. Please be
- careful about whitespace in your markup comments. Most of the
- time it doesn't matter; doxygen absorbs most whitespace, and
- both HTML and *roff are agnostic about whitespace. However,
- in &lt;pre&gt; blocks and @code/@endcode sections, spacing can
- have “<span class="quote">interesting</span>” effects.
- </p><p>
- Use either kind of grouping, as
- appropriate. <code class="filename">doxygroups.cc</code> exists for this
- purpose. See <code class="filename">stl_iterator.h</code> for a good example
- of the “<span class="quote">other</span>” kind of grouping.
- </p><p>
- Please use markup tags like @p and @a when referring to things
- such as the names of function parameters. Use @e for emphasis
- when necessary. Use @c to refer to other standard names.
- (Examples of all these abound in the present code.)
- </p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="doc_style.docbook"></a>Docbook</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="docbook.prereq"></a>Prerequisites</h4></div></div></div><p>
- Editing the DocBook sources requires an XML editor. Many
- exist: some notable options
- include <span class="command"><strong>emacs</strong></span>, <span class="application">Kate</span>,
- or <span class="application">Conglomerate</span>.
- </p><p>
- Some editors support special “<span class="quote">XML Validation</span>”
- modes that can validate the file as it is
- produced. Recommended is the <span class="command"><strong>nXML Mode</strong></span>
- for <span class="command"><strong>emacs</strong></span>.
- </p><p>
- Besides an editor, additional DocBook files and XML tools are
- also required.
- </p><p>
- Access to the DocBook stylesheets and DTD is required. The
- stylesheets are usually packaged by vendor, in something
- like <code class="filename">docbook-style-xsl</code>. To exactly match
- generated output, please use a version of the stylesheets
- equivalent
- to <code class="filename">docbook-style-xsl-1.74.0-5</code>. The
- installation directory for this package corresponds to
- the <code class="literal">XSL_STYLE_DIR</code>
- in <code class="filename">doc/Makefile.am</code> and defaults
- to <code class="filename">/usr/share/sgml/docbook/xsl-stylesheets</code>.
- </p><p>
- For processing XML, an XML processor and some style
- sheets are necessary. Defaults are <span class="command"><strong>xsltproc</strong></span>
- provided by <code class="filename">libxslt</code>.
- </p><p>
- For validating the XML document, you'll need
- something like <span class="command"><strong>xmllint</strong></span> and access to the
- DocBook DTD. These are provided
- by a vendor package like <code class="filename">lixml2</code>.
- </p><p>
- For PDF output, something that transforms valid XML to PDF is
- required. Possible solutions include <span class="command"><strong>xmlto</strong></span>,
- <a class="ulink" href="http://xmlgraphics.apache.org/fop/" target="_top">Apache
- FOP</a>, or <span class="command"><strong>prince</strong></span>. Other options are
- listed on the DocBook web <a class="ulink" href="http://wiki.docbook.org/topic/DocBookPublishingTools" target="_top">pages</a>. Please
- consult the <code class="email">&lt;<a class="email" href="mailto:libstdc++@gcc.gnu.org">libstdc++@gcc.gnu.org</a>&gt;</code> list when
- preparing printed manuals for current best practice and suggestions.
- </p><p>
- Make sure that the XML documentation and markup is valid for
- any change. This can be done easily, with the validation rules
- in the <code class="filename">Makefile</code>, which is equivalent to doing:
- </p><pre class="screen">
- <strong class="userinput"><code>
-xmllint --noout --valid <code class="filename">xml/index.xml</code>
- </code></strong>
- </pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="docbook.rules"></a>Generating the DocBook Files</h4></div></div></div><p>
- The following Makefile rules generate (in order): an HTML
- version of all the documentation, a PDF version of the same, a
- single XML document, and the result of validating the entire XML
- document.
- </p><p>
- </p><pre class="screen"><strong class="userinput"><code>make doc-html</code></strong></pre><p>
- </p><p>
- </p><pre class="screen"><strong class="userinput"><code>make doc-pdf</code></strong></pre><p>
- </p><p>
- </p><pre class="screen"><strong class="userinput"><code>make doc-xml-single</code></strong></pre><p>
- </p><p>
- </p><pre class="screen"><strong class="userinput"><code>make doc-xml-validate</code></strong></pre><p>
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="docbook.examples"></a>File Organization and Basics</h4></div></div></div><div class="literallayout"><p><br />
-      <span class="emphasis"><em>Which files are important</em></span><br />
-<br />
-      All Docbook files are in the directory<br />
-      libstdc++-v3/doc/xml<br />
-<br />
-      Inside this directory, the files of importance:<br />
-      spine.xml   - index to documentation set<br />
-      manual/spine.xml  - index to manual<br />
-      manual/*.xml   - individual chapters and sections of the manual<br />
-      faq.xml   - index to FAQ<br />
-      api.xml   - index to source level / API <br />
-<br />
-      All *.txml files are template xml files, i.e., otherwise empty files with<br />
-      the correct structure, suitable for filling in with new information.<br />
-<br />
-      <span class="emphasis"><em>Canonical Writing Style</em></span><br />
-<br />
-      class template<br />
-      function template<br />
-      member function template<br />
-      (via C++ Templates, Vandevoorde)<br />
-<br />
-      class in namespace std: allocator, not std::allocator<br />
-<br />
-      header file: iostream, not &lt;iostream&gt;<br />
-<br />
-<br />
-      <span class="emphasis"><em>General structure</em></span><br />
-<br />
-      &lt;set&gt;<br />
-      &lt;book&gt;<br />
-      &lt;/book&gt;<br />
-<br />
-      &lt;book&gt;<br />
-      &lt;chapter&gt;<br />
-      &lt;/chapter&gt;<br />
-      &lt;/book&gt;<br />
-<br />
-      &lt;book&gt; <br />
-      &lt;part&gt;<br />
-      &lt;chapter&gt;<br />
-      &lt;section&gt;<br />
-      &lt;/section&gt;<br />
-<br />
-      &lt;sect1&gt;<br />
-      &lt;/sect1&gt;<br />
-<br />
-      &lt;sect1&gt;<br />
-      &lt;sect2&gt;<br />
-      &lt;/sect2&gt;<br />
-      &lt;/sect1&gt;<br />
-      &lt;/chapter&gt;<br />
-<br />
-      &lt;chapter&gt;<br />
-      &lt;/chapter&gt;<br />
-      &lt;/part&gt;  <br />
-      &lt;/book&gt;<br />
-<br />
-      &lt;/set&gt;<br />
-    </p></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="docbook.markup"></a>Markup By Example</h4></div></div></div><p>
-Complete details on Docbook markup can be found in the DocBook Element
-Reference, <a class="ulink" href="http://www.docbook.org/tdg/en/html/part2.html" target="_top">online</a>. An
-incomplete reference for HTML to Docbook conversion is detailed in the
-table below.
-</p><div class="table"><a id="id435551"></a><p class="title"><b>Table A.1. HTML to Docbook XML markup comparison</b></p><div class="table-contents"><table summary="HTML to Docbook XML markup comparison" border="1"><colgroup><col align="left" /><col align="left" /></colgroup><thead><tr><th align="left">HTML</th><th align="left">XML</th></tr></thead><tbody><tr><td align="left">&lt;p&gt;</td><td align="left">&lt;para&gt;</td></tr><tr><td align="left">&lt;pre&gt;</td><td align="left">&lt;computeroutput&gt;, &lt;programlisting&gt;,
- &lt;literallayout&gt;</td></tr><tr><td align="left">&lt;ul&gt;</td><td align="left">&lt;itemizedlist&gt;</td></tr><tr><td align="left">&lt;ol&gt;</td><td align="left">&lt;orderedlist&gt;</td></tr><tr><td align="left">&lt;il&gt;</td><td align="left">&lt;listitem&gt;</td></tr><tr><td align="left">&lt;dl&gt;</td><td align="left">&lt;variablelist&gt;</td></tr><tr><td align="left">&lt;dt&gt;</td><td align="left">&lt;term&gt;</td></tr><tr><td align="left">&lt;dd&gt;</td><td align="left">&lt;listitem&gt;</td></tr><tr><td align="left">&lt;a href=""&gt;</td><td align="left">&lt;ulink url=""&gt;</td></tr><tr><td align="left">&lt;code&gt;</td><td align="left">&lt;literal&gt;, &lt;programlisting&gt;</td></tr><tr><td align="left">&lt;strong&gt;</td><td align="left">&lt;emphasis&gt;</td></tr><tr><td align="left">&lt;em&gt;</td><td align="left">&lt;emphasis&gt;</td></tr><tr><td align="left">"</td><td align="left">&lt;quote&gt;</td></tr></tbody></table></div></div><br class="table-break" /><p>
- And examples of detailed markup for which there are no real HTML
- equivalents are listed in the table below.
-</p><div class="table"><a id="id500888"></a><p class="title"><b>Table A.2. Docbook XML Element Use</b></p><div class="table-contents"><table summary="Docbook XML Element Use" border="1"><colgroup><col align="left" /><col align="left" /></colgroup><thead><tr><th align="left">Element</th><th align="left">Use</th></tr></thead><tbody><tr><td align="left">&lt;structname&gt;</td><td align="left">&lt;structname&gt;char_traits&lt;/structname&gt;</td></tr><tr><td align="left">&lt;classname&gt;</td><td align="left">&lt;classname&gt;string&lt;/classname&gt;</td></tr><tr><td align="left">&lt;function&gt;</td><td align="left">
- <p>&lt;function&gt;clear()&lt;/function&gt;</p>
- <p>&lt;function&gt;fs.clear()&lt;/function&gt;</p>
- </td></tr><tr><td align="left">&lt;type&gt;</td><td align="left">&lt;type&gt;long long&lt;/type&gt;</td></tr><tr><td align="left">&lt;varname&gt;</td><td align="left">&lt;varname&gt;fs&lt;/varname&gt;</td></tr><tr><td align="left">&lt;literal&gt;</td><td align="left">
- <p>&lt;literal&gt;-Weffc++&lt;/literal&gt;</p>
- <p>&lt;literal&gt;rel_ops&lt;/literal&gt;</p>
- </td></tr><tr><td align="left">&lt;constant&gt;</td><td align="left">
- <p>&lt;constant&gt;_GNU_SOURCE&lt;/constant&gt;</p>
- <p>&lt;constant&gt;3.0&lt;/constant&gt;</p>
- </td></tr><tr><td align="left">&lt;command&gt;</td><td align="left">&lt;command&gt;g++&lt;/command&gt;</td></tr><tr><td align="left">&lt;errortext&gt;</td><td align="left">&lt;errortext&gt;In instantiation of&lt;/errortext&gt;</td></tr><tr><td align="left">&lt;filename&gt;</td><td align="left">
- <p>&lt;filename class="headerfile"&gt;ctype.h&lt;/filename&gt;</p>
- <p>&lt;filename class="directory"&gt;/home/gcc/build&lt;/filename&gt;</p>
- </td></tr></tbody></table></div></div><br class="table-break" /></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="source_code_style.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_contributing.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="source_design_notes.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Coding Style </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Design Notes</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/dynamic_memory.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/dynamic_memory.html
deleted file mode 100644
index 2a3d1368b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/dynamic_memory.html
+++ /dev/null
@@ -1,69 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 5. Dynamic Memory</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="support.html" title="Part II.  Support" /><link rel="prev" href="bk01pt02ch04s03.html" title="NULL" /><link rel="next" href="termination.html" title="Chapter 6. Termination" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 5. Dynamic Memory</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt02ch04s03.html">Prev</a> </td><th width="60%" align="center">Part II. 
- Support
-
-</th><td width="20%" align="right"> <a accesskey="n" href="termination.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.support.memory"></a>Chapter 5. Dynamic Memory</h2></div></div></div><p>
- There are six flavors each of <code class="function">new</code> and
- <code class="function">delete</code>, so make certain that you're using the right
- ones. Here are quickie descriptions of <code class="function">new</code>:
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- single object form, throwing a
- <code class="classname">bad_alloc</code> on errors; this is what most
- people are used to using
- </p></li><li><p>
- Single object "nothrow" form, returning NULL on errors
- </p></li><li><p>
- Array <code class="function">new</code>, throwing
- <code class="classname">bad_alloc</code> on errors
- </p></li><li><p>
- Array nothrow <code class="function">new</code>, returning
- <code class="constant">NULL</code> on errors
- </p></li><li><p>
- Placement <code class="function">new</code>, which does nothing (like
- it's supposed to)
- </p></li><li><p>
- Placement array <code class="function">new</code>, which also does
- nothing
- </p></li></ul></div><p>
- They are distinguished by the parameters that you pass to them, like
- any other overloaded function. The six flavors of <code class="function">delete</code>
- are distinguished the same way, but none of them are allowed to throw
- an exception under any circumstances anyhow. (They match up for
- completeness' sake.)
- </p><p>
- Remember that it is perfectly okay to call <code class="function">delete</code> on a
- NULL pointer! Nothing happens, by definition. That is not the
- same thing as deleting a pointer twice.
- </p><p>
- By default, if one of the “<span class="quote">throwing <code class="function">new</code>s</span>” can't
- allocate the memory requested, it tosses an instance of a
- <code class="classname">bad_alloc</code> exception (or, technically, some class derived
- from it). You can change this by writing your own function (called a
- new-handler) and then registering it with <code class="function">set_new_handler()</code>:
- </p><pre class="programlisting">
- typedef void (*PFV)(void);
-
- static char* safety;
- static PFV old_handler;
-
- void my_new_handler ()
- {
- delete[] safety;
- popup_window ("Dude, you are running low on heap memory. You
- should, like, close some windows, or something.
- The next time you run out, we're gonna burn!");
- set_new_handler (old_handler);
- return;
- }
-
- int main ()
- {
- safety = new char[500000];
- old_handler = set_new_handler (&amp;my_new_handler);
- ...
- }
- </pre><p>
- <code class="classname">bad_alloc</code> is derived from the base <code class="classname">exception</code>
- class defined in Chapter 19.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt02ch04s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="support.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="termination.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">NULL </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 6. Termination</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/exceptions.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/exceptions.html
deleted file mode 100644
index 9ad183a86..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/exceptions.html
+++ /dev/null
@@ -1,22 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 7. Exceptions</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="diagnostics.html" title="Part III.  Diagnostics" /><link rel="prev" href="diagnostics.html" title="Part III.  Diagnostics" /><link rel="next" href="bk01pt03ch07s02.html" title="Adding Data to Exceptions" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 7. Exceptions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="diagnostics.html">Prev</a> </td><th width="60%" align="center">Part III. 
- Diagnostics
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt03ch07s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.diagnostics.exceptions"></a>Chapter 7. Exceptions</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="exceptions.html#manual.diagnostics.exceptions.hierarchy">Exception Classes</a></span></dt><dt><span class="sect1"><a href="bk01pt03ch07s02.html">Adding Data to Exceptions</a></span></dt><dt><span class="sect1"><a href="bk01pt03ch07s03.html">Cancellation</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.diagnostics.exceptions.hierarchy"></a>Exception Classes</h2></div></div></div><p>
- All exception objects are defined in one of the standard header
- files: <code class="filename">exception</code>,
- <code class="filename">stdexcept</code>, <code class="filename">new</code>, and
- <code class="filename">typeinfo</code>.
- </p><p>
- The base exception object is <code class="classname">exception</code>,
- located in <code class="filename">exception</code>. This object has no
- <code class="classname">string</code> member.
- </p><p>
- Derived from this are several classes that may have a
- <code class="classname">string</code> member: a full hierarchy can be
- found in the <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00233.html" target="_top">source documentation</a>.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="diagnostics.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="diagnostics.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt03ch07s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part III. 
- Diagnostics
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Adding Data to Exceptions</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_algorithms.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_algorithms.html
deleted file mode 100644
index 0a23ad9b7..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_algorithms.html
+++ /dev/null
@@ -1,23 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 35. Algorithms</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="ext_utilities.html" title="Chapter 34. Utilities" /><link rel="next" href="ext_numerics.html" title="Chapter 36. Numerics" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 35. Algorithms</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ext_utilities.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="ext_numerics.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.algorithms"></a>Chapter 35. Algorithms</h2></div></div></div><p>25.1.6 (count, count_if) is extended with two more versions of count
- and count_if. The standard versions return their results. The
- additional signatures return void, but take a final parameter by
- reference to which they assign their results, e.g.,
-</p><pre class="programlisting">
- void count (first, last, value, n);</pre><p>25.2 (mutating algorithms) is extended with two families of signatures,
- random_sample and random_sample_n.
-</p><p>25.2.1 (copy) is extended with
-</p><pre class="programlisting">
- copy_n (_InputIter first, _Size count, _OutputIter result);</pre><p>which copies the first 'count' elements at 'first' into 'result'.
-</p><p>25.3 (sorting 'n' heaps 'n' stuff) is extended with some helper
- predicates. Look in the doxygen-generated pages for notes on these.
-</p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">is_heap</code> tests whether or not a range is a heap.</p></li><li><p><code class="code">is_sorted</code> tests whether or not a range is sorted in
- nondescending order.</p></li></ul></div><p>25.3.8 (lexicographical_compare) is extended with
-</p><pre class="programlisting">
- lexicographical_compare_3way(_InputIter1 first1, _InputIter1 last1,
- _InputIter2 first2, _InputIter2 last2)</pre><p>which does... what?
-</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ext_utilities.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ext_numerics.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 34. Utilities </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 36. Numerics</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_allocators.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_allocators.html
deleted file mode 100644
index a9daf7959..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_allocators.html
+++ /dev/null
@@ -1,397 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 32. Allocators</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="bk01pt12ch31s05.html" title="Testing" /><link rel="next" href="bitmap_allocator.html" title="bitmap_allocator" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 32. Allocators</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch31s05.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bitmap_allocator.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.allocator"></a>Chapter 32. Allocators</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="ext_allocators.html#manual.ext.allocator.mt">mt_allocator</a></span></dt><dd><dl><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.intro">Intro</a></span></dt><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.example_single">Single Thread Example</a></span></dt><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.example_multi">Multiple Thread Example</a></span></dt></dl></dd><dt><span class="sect1"><a href="bitmap_allocator.html">bitmap_allocator</a></span></dt><dd><dl><dt><span class="sect2"><a href="bitmap_allocator.html#allocator.bitmap.design">Design</a></span></dt><dt><span class="sect2"><a href="bitmap_allocator.html#allocator.bitmap.impl">Implementation</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.allocator.mt"></a>mt_allocator</h2></div></div></div><p>
-</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.mt.intro"></a>Intro</h3></div></div></div><p>
- The mt allocator [hereinafter referred to simply as "the allocator"]
- is a fixed size (power of two) allocator that was initially
- developed specifically to suit the needs of multi threaded
- applications [hereinafter referred to as an MT application]. Over
- time the allocator has evolved and been improved in many ways, in
- particular it now also does a good job in single threaded
- applications [hereinafter referred to as a ST application]. (Note:
- In this document, when referring to single threaded applications
- this also includes applications that are compiled with gcc without
- thread support enabled. This is accomplished using ifdef's on
- __GTHREADS). This allocator is tunable, very flexible, and capable
- of high-performance.
-</p><p>
- The aim of this document is to describe - from an application point of
- view - the "inner workings" of the allocator.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.mt.design_issues"></a>Design Issues</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="allocator.mt.overview"></a>Overview</h4></div></div></div><p> There are three general components to the allocator: a datum
-describing the characteristics of the memory pool, a policy class
-containing this pool that links instantiation types to common or
-individual pools, and a class inheriting from the policy class that is
-the actual allocator.
-</p><p>The datum describing pools characteristics is
-</p><pre class="programlisting">
- template&lt;bool _Thread&gt;
- class __pool
-</pre><p> This class is parametrized on thread support, and is explicitly
-specialized for both multiple threads (with <code class="code">bool==true</code>)
-and single threads (via <code class="code">bool==false</code>.) It is possible to
-use a custom pool datum instead of the default class that is provided.
-</p><p> There are two distinct policy classes, each of which can be used
-with either type of underlying pool datum.
-</p><pre class="programlisting">
- template&lt;bool _Thread&gt;
- struct __common_pool_policy
-
- template&lt;typename _Tp, bool _Thread&gt;
- struct __per_type_pool_policy
-</pre><p> The first policy, <code class="code">__common_pool_policy</code>, implements a
-common pool. This means that allocators that are instantiated with
-different types, say <code class="code">char</code> and <code class="code">long</code> will both
-use the same pool. This is the default policy.
-</p><p> The second policy, <code class="code">__per_type_pool_policy</code>, implements
-a separate pool for each instantiating type. Thus, <code class="code">char</code>
-and <code class="code">long</code> will use separate pools. This allows per-type
-tuning, for instance.
-</p><p> Putting this all together, the actual allocator class is
-</p><pre class="programlisting">
- template&lt;typename _Tp, typename _Poolp = __default_policy&gt;
- class __mt_alloc : public __mt_alloc_base&lt;_Tp&gt;, _Poolp
-</pre><p> This class has the interface required for standard library allocator
-classes, namely member functions <code class="code">allocate</code> and
-<code class="code">deallocate</code>, plus others.
-</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.mt.impl"></a>Implementation</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="allocator.mt.tune"></a>Tunable Parameters</h4></div></div></div><p>Certain allocation parameters can be modified, or tuned. There
-exists a nested <code class="code">struct __pool_base::_Tune</code> that contains all
-these parameters, which include settings for
-</p><div class="itemizedlist"><ul type="disc"><li><p>Alignment</p></li><li><p>Maximum bytes before calling <code class="code">::operator new</code> directly</p></li><li><p>Minimum bytes</p></li><li><p>Size of underlying global allocations</p></li><li><p>Maximum number of supported threads</p></li><li><p>Migration of deallocations to the global free list</p></li><li><p>Shunt for global <code class="code">new</code> and <code class="code">delete</code></p></li></ul></div><p>Adjusting parameters for a given instance of an allocator can only
-happen before any allocations take place, when the allocator itself is
-initialized. For instance:
-</p><pre class="programlisting">
-#include &lt;ext/mt_allocator.h&gt;
-
-struct pod
-{
- int i;
- int j;
-};
-
-int main()
-{
- typedef pod value_type;
- typedef __gnu_cxx::__mt_alloc&lt;value_type&gt; allocator_type;
- typedef __gnu_cxx::__pool_base::_Tune tune_type;
-
- tune_type t_default;
- tune_type t_opt(16, 5120, 32, 5120, 20, 10, false);
- tune_type t_single(16, 5120, 32, 5120, 1, 10, false);
-
- tune_type t;
- t = allocator_type::_M_get_options();
- allocator_type::_M_set_options(t_opt);
- t = allocator_type::_M_get_options();
-
- allocator_type a;
- allocator_type::pointer p1 = a.allocate(128);
- allocator_type::pointer p2 = a.allocate(5128);
-
- a.deallocate(p1, 128);
- a.deallocate(p2, 5128);
-
- return 0;
-}
-</pre></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="allocator.mt.init"></a>Initialization</h4></div></div></div><p>
-The static variables (pointers to freelists, tuning parameters etc)
-are initialized as above, or are set to the global defaults.
-</p><p>
-The very first allocate() call will always call the
-_S_initialize_once() function. In order to make sure that this
-function is called exactly once we make use of a __gthread_once call
-in MT applications and check a static bool (_S_init) in ST
-applications.
-</p><p>
-The _S_initialize() function:
-- If the GLIBCXX_FORCE_NEW environment variable is set, it sets the bool
- _S_force_new to true and then returns. This will cause subsequent calls to
- allocate() to return memory directly from a new() call, and deallocate will
- only do a delete() call.
-</p><p>
-- If the GLIBCXX_FORCE_NEW environment variable is not set, both ST and MT
- applications will:
- - Calculate the number of bins needed. A bin is a specific power of two size
- of bytes. I.e., by default the allocator will deal with requests of up to
- 128 bytes (or whatever the value of _S_max_bytes is when _S_init() is
- called). This means that there will be bins of the following sizes
- (in bytes): 1, 2, 4, 8, 16, 32, 64, 128.
-
- - Create the _S_binmap array. All requests are rounded up to the next
- "large enough" bin. I.e., a request for 29 bytes will cause a block from
- the "32 byte bin" to be returned to the application. The purpose of
- _S_binmap is to speed up the process of finding out which bin to use.
- I.e., the value of _S_binmap[ 29 ] is initialized to 5 (bin 5 = 32 bytes).
-</p><p>
- - Create the _S_bin array. This array consists of bin_records. There will be
- as many bin_records in this array as the number of bins that we calculated
- earlier. I.e., if _S_max_bytes = 128 there will be 8 entries.
- Each bin_record is then initialized:
- - bin_record-&gt;first = An array of pointers to block_records. There will be
- as many block_records pointers as there are maximum number of threads
- (in a ST application there is only 1 thread, in a MT application there
- are _S_max_threads).
- This holds the pointer to the first free block for each thread in this
- bin. I.e., if we would like to know where the first free block of size 32
- for thread number 3 is we would look this up by: _S_bin[ 5 ].first[ 3 ]
-
- The above created block_record pointers members are now initialized to
- their initial values. I.e. _S_bin[ n ].first[ n ] = NULL;
-</p><p>
-- Additionally a MT application will:
- - Create a list of free thread id's. The pointer to the first entry
- is stored in _S_thread_freelist_first. The reason for this approach is
- that the __gthread_self() call will not return a value that corresponds to
- the maximum number of threads allowed but rather a process id number or
- something else. So what we do is that we create a list of thread_records.
- This list is _S_max_threads long and each entry holds a size_t thread_id
- which is initialized to 1, 2, 3, 4, 5 and so on up to _S_max_threads.
- Each time a thread calls allocate() or deallocate() we call
- _S_get_thread_id() which looks at the value of _S_thread_key which is a
- thread local storage pointer. If this is NULL we know that this is a newly
- created thread and we pop the first entry from this list and saves the
- pointer to this record in the _S_thread_key variable. The next time
- we will get the pointer to the thread_record back and we use the
- thread_record-&gt;thread_id as identification. I.e., the first thread that
- calls allocate will get the first record in this list and thus be thread
- number 1 and will then find the pointer to its first free 32 byte block
- in _S_bin[ 5 ].first[ 1 ]
- When we create the _S_thread_key we also define a destructor
- (_S_thread_key_destr) which means that when the thread dies, this
- thread_record is returned to the front of this list and the thread id
- can then be reused if a new thread is created.
- This list is protected by a mutex (_S_thread_freelist_mutex) which is only
- locked when records are removed or added to the list.
-</p><p>
- - Initialize the free and used counters of each bin_record:
- - bin_record-&gt;free = An array of size_t. This keeps track of the number
- of blocks on a specific thread's freelist in each bin. I.e., if a thread
- has 12 32-byte blocks on it's freelists and allocates one of these, this
- counter would be decreased to 11.
-
- - bin_record-&gt;used = An array of size_t. This keeps track of the number
- of blocks currently in use of this size by this thread. I.e., if a thread
- has made 678 requests (and no deallocations...) of 32-byte blocks this
- counter will read 678.
-
- The above created arrays are now initialized with their initial values.
- I.e. _S_bin[ n ].free[ n ] = 0;
-</p><p>
- - Initialize the mutex of each bin_record: The bin_record-&gt;mutex
- is used to protect the global freelist. This concept of a global
- freelist is explained in more detail in the section "A multi
- threaded example", but basically this mutex is locked whenever a
- block of memory is retrieved or returned to the global freelist
- for this specific bin. This only occurs when a number of blocks
- are grabbed from the global list to a thread specific list or when
- a thread decides to return some blocks to the global freelist.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="allocator.mt.deallocation"></a>Deallocation Notes</h4></div></div></div><p> Notes about deallocation. This allocator does not explicitly
-release memory. Because of this, memory debugging programs like
-valgrind or purify may notice leaks: sorry about this
-inconvenience. Operating systems will reclaim allocated memory at
-program termination anyway. If sidestepping this kind of noise is
-desired, there are three options: use an allocator, like
-<code class="code">new_allocator</code> that releases memory while debugging, use
-GLIBCXX_FORCE_NEW to bypass the allocator's internal pools, or use a
-custom pool datum that releases resources on destruction.
-</p><p>
- On systems with the function <code class="code">__cxa_atexit</code>, the
-allocator can be forced to free all memory allocated before program
-termination with the member function
-<code class="code">__pool_type::_M_destroy</code>. However, because this member
-function relies on the precise and exactly-conforming ordering of
-static destructors, including those of a static local
-<code class="code">__pool</code> object, it should not be used, ever, on systems
-that don't have the necessary underlying support. In addition, in
-practice, forcing deallocation can be tricky, as it requires the
-<code class="code">__pool</code> object to be fully-constructed before the object
-that uses it is fully constructed. For most (but not all) STL
-containers, this works, as an instance of the allocator is constructed
-as part of a container's constructor. However, this assumption is
-implementation-specific, and subject to change. For an example of a
-pool that frees memory, see the following
- <a class="ulink" href="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/ext/mt_allocator/deallocate_local-6.cc?view=markup" target="_top">
- example.</a>
-</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.mt.example_single"></a>Single Thread Example</h3></div></div></div><p>
-Let's start by describing how the data on a freelist is laid out in memory.
-This is the first two blocks in freelist for thread id 3 in bin 3 (8 bytes):
-</p><pre class="programlisting">
-+----------------+
-| next* ---------|--+ (_S_bin[ 3 ].first[ 3 ] points here)
-| | |
-| | |
-| | |
-+----------------+ |
-| thread_id = 3 | |
-| | |
-| | |
-| | |
-+----------------+ |
-| DATA | | (A pointer to here is what is returned to the
-| | | the application when needed)
-| | |
-| | |
-| | |
-| | |
-| | |
-| | |
-+----------------+ |
-+----------------+ |
-| next* |&lt;-+ (If next == NULL it's the last one on the list)
-| |
-| |
-| |
-+----------------+
-| thread_id = 3 |
-| |
-| |
-| |
-+----------------+
-| DATA |
-| |
-| |
-| |
-| |
-| |
-| |
-| |
-+----------------+
-</pre><p>
-With this in mind we simplify things a bit for a while and say that there is
-only one thread (a ST application). In this case all operations are made to
-what is referred to as the global pool - thread id 0 (No thread may be
-assigned this id since they span from 1 to _S_max_threads in a MT application).
-</p><p>
-When the application requests memory (calling allocate()) we first look at the
-requested size and if this is &gt; _S_max_bytes we call new() directly and return.
-</p><p>
-If the requested size is within limits we start by finding out from which
-bin we should serve this request by looking in _S_binmap.
-</p><p>
-A quick look at _S_bin[ bin ].first[ 0 ] tells us if there are any blocks of
-this size on the freelist (0). If this is not NULL - fine, just remove the
-block that _S_bin[ bin ].first[ 0 ] points to from the list,
-update _S_bin[ bin ].first[ 0 ] and return a pointer to that blocks data.
-</p><p>
-If the freelist is empty (the pointer is NULL) we must get memory from the
-system and build us a freelist within this memory. All requests for new memory
-is made in chunks of _S_chunk_size. Knowing the size of a block_record and
-the bytes that this bin stores we then calculate how many blocks we can create
-within this chunk, build the list, remove the first block, update the pointer
-(_S_bin[ bin ].first[ 0 ]) and return a pointer to that blocks data.
-</p><p>
-Deallocation is equally simple; the pointer is casted back to a block_record
-pointer, lookup which bin to use based on the size, add the block to the front
-of the global freelist and update the pointer as needed
-(_S_bin[ bin ].first[ 0 ]).
-</p><p>
-The decision to add deallocated blocks to the front of the freelist was made
-after a set of performance measurements that showed that this is roughly 10%
-faster than maintaining a set of "last pointers" as well.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.mt.example_multi"></a>Multiple Thread Example</h3></div></div></div><p>
-In the ST example we never used the thread_id variable present in each block.
-Let's start by explaining the purpose of this in a MT application.
-</p><p>
-The concept of "ownership" was introduced since many MT applications
-allocate and deallocate memory to shared containers from different
-threads (such as a cache shared amongst all threads). This introduces
-a problem if the allocator only returns memory to the current threads
-freelist (I.e., there might be one thread doing all the allocation and
-thus obtaining ever more memory from the system and another thread
-that is getting a longer and longer freelist - this will in the end
-consume all available memory).
-</p><p>
-Each time a block is moved from the global list (where ownership is
-irrelevant), to a threads freelist (or when a new freelist is built
-from a chunk directly onto a threads freelist or when a deallocation
-occurs on a block which was not allocated by the same thread id as the
-one doing the deallocation) the thread id is set to the current one.
-</p><p>
-What's the use? Well, when a deallocation occurs we can now look at
-the thread id and find out if it was allocated by another thread id
-and decrease the used counter of that thread instead, thus keeping the
-free and used counters correct. And keeping the free and used counters
-corrects is very important since the relationship between these two
-variables decides if memory should be returned to the global pool or
-not when a deallocation occurs.
-</p><p>
-When the application requests memory (calling allocate()) we first
-look at the requested size and if this is &gt;_S_max_bytes we call new()
-directly and return.
-</p><p>
-If the requested size is within limits we start by finding out from which
-bin we should serve this request by looking in _S_binmap.
-</p><p>
-A call to _S_get_thread_id() returns the thread id for the calling thread
-(and if no value has been set in _S_thread_key, a new id is assigned and
-returned).
-</p><p>
-A quick look at _S_bin[ bin ].first[ thread_id ] tells us if there are
-any blocks of this size on the current threads freelist. If this is
-not NULL - fine, just remove the block that _S_bin[ bin ].first[
-thread_id ] points to from the list, update _S_bin[ bin ].first[
-thread_id ], update the free and used counters and return a pointer to
-that blocks data.
-</p><p>
-If the freelist is empty (the pointer is NULL) we start by looking at
-the global freelist (0). If there are blocks available on the global
-freelist we lock this bins mutex and move up to block_count (the
-number of blocks of this bins size that will fit into a _S_chunk_size)
-or until end of list - whatever comes first - to the current threads
-freelist and at the same time change the thread_id ownership and
-update the counters and pointers. When the bins mutex has been
-unlocked, we remove the block that _S_bin[ bin ].first[ thread_id ]
-points to from the list, update _S_bin[ bin ].first[ thread_id ],
-update the free and used counters, and return a pointer to that blocks
-data.
-</p><p>
-The reason that the number of blocks moved to the current threads
-freelist is limited to block_count is to minimize the chance that a
-subsequent deallocate() call will return the excess blocks to the
-global freelist (based on the _S_freelist_headroom calculation, see
-below).
-</p><p>
-However if there isn't any memory on the global pool we need to get
-memory from the system - this is done in exactly the same way as in a
-single threaded application with one major difference; the list built
-in the newly allocated memory (of _S_chunk_size size) is added to the
-current threads freelist instead of to the global.
-</p><p>
-The basic process of a deallocation call is simple: always add the
-block to the front of the current threads freelist and update the
-counters and pointers (as described earlier with the specific check of
-ownership that causes the used counter of the thread that originally
-allocated the block to be decreased instead of the current threads
-counter).
-</p><p>
-And here comes the free and used counters to service. Each time a
-deallocation() call is made, the length of the current threads
-freelist is compared to the amount memory in use by this thread.
-</p><p>
-Let's go back to the example of an application that has one thread
-that does all the allocations and one that deallocates. Both these
-threads use say 516 32-byte blocks that was allocated during thread
-creation for example. Their used counters will both say 516 at this
-point. The allocation thread now grabs 1000 32-byte blocks and puts
-them in a shared container. The used counter for this thread is now
-1516.
-</p><p>
-The deallocation thread now deallocates 500 of these blocks. For each
-deallocation made the used counter of the allocating thread is
-decreased and the freelist of the deallocation thread gets longer and
-longer. But the calculation made in deallocate() will limit the length
-of the freelist in the deallocation thread to _S_freelist_headroom %
-of it's used counter. In this case, when the freelist (given that the
-_S_freelist_headroom is at it's default value of 10%) exceeds 52
-(516/10) blocks will be returned to the global pool where the
-allocating thread may pick them up and reuse them.
-</p><p>
-In order to reduce lock contention (since this requires this bins
-mutex to be locked) this operation is also made in chunks of blocks
-(just like when chunks of blocks are moved from the global freelist to
-a threads freelist mentioned above). The "formula" used can probably
-be improved to further reduce the risk of blocks being "bounced back
-and forth" between freelists.
-</p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch31s05.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bitmap_allocator.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Testing </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> bitmap_allocator</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_compile_checks.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_compile_checks.html
deleted file mode 100644
index 132c8b619..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_compile_checks.html
+++ /dev/null
@@ -1,40 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 29. Compile Time Checks</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="bk01pt12pr03.html" title="" /><link rel="next" href="debug_mode.html" title="Chapter 30. Debug Mode" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 29. Compile Time Checks</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12pr03.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="debug_mode.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.compile_checks"></a>Chapter 29. Compile Time Checks</h2></div></div></div><p>
- Also known as concept checking.
- </p><p>In 1999, SGI added <span class="emphasis"><em>concept checkers</em></span> to their implementation
- of the STL: code which checked the template parameters of
- instantiated pieces of the STL, in order to insure that the parameters
- being used met the requirements of the standard. For example,
- the Standard requires that types passed as template parameters to
- <code class="code">vector</code> be “<span class="quote">Assignable</span>” (which means what you think
- it means). The checking was done during compilation, and none of
- the code was executed at runtime.
- </p><p>Unfortunately, the size of the compiler files grew significantly
- as a result. The checking code itself was cumbersome. And bugs
- were found in it on more than one occasion.
- </p><p>The primary author of the checking code, Jeremy Siek, had already
- started work on a replacement implementation. The new code has been
- formally reviewed and accepted into
- <a class="ulink" href="http://www.boost.org/libs/concept_check/concept_check.htm" target="_top">the
- Boost libraries</a>, and we are pleased to incorporate it into the
- GNU C++ library.
- </p><p>The new version imposes a much smaller space overhead on the generated
- object file. The checks are also cleaner and easier to read and
- understand.
- </p><p>They are off by default for all versions of GCC from 3.0 to 3.4 (the
- latest release at the time of writing).
- They can be enabled at configure time with
- <a class="ulink" href="../configopts.html" target="_top"><code class="literal">--enable-concept-checks</code></a>.
- You can enable them on a per-translation-unit basis with
- <code class="code">#define _GLIBCXX_CONCEPT_CHECKS</code> for GCC 3.4 and higher
- (or with <code class="code">#define _GLIBCPP_CONCEPT_CHECKS</code> for versions
- 3.1, 3.2 and 3.3).
- </p><p>Please note that the upcoming C++ standard has first-class
- support for template parameter constraints based on concepts in the core
- language. This will obviate the need for the library-simulated concept
- checking described above.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12pr03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="debug_mode.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 30. Debug Mode</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_concurrency.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_concurrency.html
deleted file mode 100644
index dc986ee9c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_concurrency.html
+++ /dev/null
@@ -1,91 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 40. Concurrency</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="ext_demangling.html" title="Chapter 39. Demangling" /><link rel="next" href="bk01pt12ch40s02.html" title="Implementation" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 40. Concurrency</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ext_demangling.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch40s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.concurrency"></a>Chapter 40. Concurrency</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="ext_concurrency.html#manual.ext.concurrency.design">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="ext_concurrency.html#manual.ext.concurrency.design.threads">Interface to Locks and Mutexes</a></span></dt><dt><span class="sect2"><a href="ext_concurrency.html#manual.ext.concurrency.design.atomics">Interface to Atomic Functions</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch40s02.html">Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch40s02.html#manual.ext.concurrency.impl.atomic_fallbacks">Using Builtin Atomic Functions</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch40s02.html#manual.ext.concurrency.impl.thread">Thread Abstraction</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch40s03.html">Use</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.concurrency.design"></a>Design</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.concurrency.design.threads"></a>Interface to Locks and Mutexes</h3></div></div></div><p>The file &lt;ext/concurrence.h&gt; contains all the higher-level
-constructs for playing with threads. In contrast to the atomics layer,
-the concurrence layer consists largely of types. All types are defined within <code class="code">namespace __gnu_cxx</code>.
-</p><p>
-These types can be used in a portable manner, regardless of the
-specific environment. They are carefully designed to provide optimum
-efficiency and speed, abstracting out underlying thread calls and
-accesses when compiling for single-threaded situations (even on hosts
-that support multiple threads.)
-</p><p>The enumerated type <code class="code">_Lock_policy</code> details the set of
-available locking
-policies: <code class="code">_S_single</code>, <code class="code">_S_mutex</code>,
-and <code class="code">_S_atomic</code>.
-</p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">_S_single</code></p><p>Indicates single-threaded code that does not need locking.
-</p></li><li><p><code class="code">_S_mutex</code></p><p>Indicates multi-threaded code using thread-layer abstractions.
-</p></li><li><p><code class="code">_S_atomic</code></p><p>Indicates multi-threaded code using atomic operations.
-</p></li></ul></div><p>The compile-time constant <code class="code">__default_lock_policy</code> is set
-to one of the three values above, depending on characteristics of the
-host environment and the current compilation flags.
-</p><p>Two more datatypes make up the rest of the
-interface: <code class="code">__mutex</code>, and <code class="code">__scoped_lock</code>.
-</p><p>
-</p><p>The scoped lock idiom is well-discussed within the C++
-community. This version takes a <code class="code">__mutex</code> reference, and
-locks it during construction of <code class="code">__scoped_locke</code> and
-unlocks it during destruction. This is an efficient way of locking
-critical sections, while retaining exception-safety.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.ext.concurrency.design.atomics"></a>Interface to Atomic Functions</h3></div></div></div><p>
-Two functions and one type form the base of atomic support.
-</p><p>The type <code class="code">_Atomic_word</code> is a signed integral type
-supporting atomic operations.
-</p><p>
-The two functions functions are:
-</p><pre class="programlisting">
-_Atomic_word
-__exchange_and_add_dispatch(volatile _Atomic_word*, int);
-
-void
-__atomic_add_dispatch(volatile _Atomic_word*, int);
-</pre><p>Both of these functions are declared in the header file
-&lt;ext/atomicity.h&gt;, and are in <code class="code">namespace __gnu_cxx</code>.
-</p><div class="itemizedlist"><ul type="disc"><li><p>
-<code class="code">
-__exchange_and_add_dispatch
-</code>
-</p><p>Adds the second argument's value to the first argument. Returns the old value.
-</p></li><li><p>
-<code class="code">
-__atomic_add_dispatch
-</code>
-</p><p>Adds the second argument's value to the first argument. Has no return value.
-</p></li></ul></div><p>
-These functions forward to one of several specialized helper
-functions, depending on the circumstances. For instance,
-</p><p>
-<code class="code">
-__exchange_and_add_dispatch
-</code>
-</p><p>
-Calls through to either of:
-</p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">__exchange_and_add</code>
-</p><p>Multi-thread version. Inlined if compiler-generated builtin atomics
-can be used, otherwise resolved at link time to a non-builtin code
-sequence.
-</p></li><li><p><code class="code">__exchange_and_add_single</code>
-</p><p>Single threaded version. Inlined.</p></li></ul></div><p>However, only <code class="code">__exchange_and_add_dispatch</code>
-and <code class="code">__atomic_add_dispatch</code> should be used. These functions
-can be used in a portable manner, regardless of the specific
-environment. They are carefully designed to provide optimum efficiency
-and speed, abstracting out atomic accesses when they are not required
-(even on hosts that support compiler intrinsics for atomic
-operations.)
-</p><p>
-In addition, there are two macros
-</p><p>
-<code class="code">
-_GLIBCXX_READ_MEM_BARRIER
-</code>
-</p><p>
-<code class="code">
-_GLIBCXX_WRITE_MEM_BARRIER
-</code>
-</p><p>
-Which expand to the appropriate write and read barrier required by the
-host hardware and operating system.
-</p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ext_demangling.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch40s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 39. Demangling </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Implementation</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_containers.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_containers.html
deleted file mode 100644
index 48abd5ab4..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_containers.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 33. Containers</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="bitmap_allocator.html" title="bitmap_allocator" /><link rel="next" href="bk01pt12ch33s02.html" title="HP/SGI" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 33. Containers</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bitmap_allocator.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch33s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.containers"></a>Chapter 33. Containers</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="ext_containers.html#manual.ext.containers.pbds">Policy Based Data Structures</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch33s02.html">HP/SGI</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch33s03.html">Deprecated HP/SGI</a></span></dt></dl></div><p>
- </p><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.containers.pbds"></a>Policy Based Data Structures</h2></div></div></div><p>
- <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/ext/pb_ds/index.html" target="_top">More details here</a>.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bitmap_allocator.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch33s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">bitmap_allocator </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> HP/SGI</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_demangling.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_demangling.html
deleted file mode 100644
index 28fbd814c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_demangling.html
+++ /dev/null
@@ -1,74 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 39. Demangling</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="ext_io.html" title="Chapter 38. Input and Output" /><link rel="next" href="ext_concurrency.html" title="Chapter 40. Concurrency" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 39. Demangling</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ext_io.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="ext_concurrency.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.demangle"></a>Chapter 39. Demangling</h2></div></div></div><p>
- Transforming C++ ABI identifiers (like RTTI symbols) into the
- original C++ source identifiers is called
- “<span class="quote">demangling.</span>”
- </p><p>
- If you have read the <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/namespaceabi.html" target="_top">source
- documentation for <code class="code">namespace abi</code></a> then you are
- aware of the cross-vendor C++ ABI in use by GCC. One of the
- exposed functions is used for demangling,
- <code class="code">abi::__cxa_demangle</code>.
- </p><p>
- In programs like <span class="command"><strong>c++filt</strong></span>, the linker, and other tools
- have the ability to decode C++ ABI names, and now so can you.
- </p><p>
- (The function itself might use different demanglers, but that's the
- whole point of abstract interfaces. If we change the implementation,
- you won't notice.)
- </p><p>
- Probably the only times you'll be interested in demangling at runtime
- are when you're seeing <code class="code">typeid</code> strings in RTTI, or when
- you're handling the runtime-support exception classes. For example:
- </p><pre class="programlisting">
-#include &lt;exception&gt;
-#include &lt;iostream&gt;
-#include &lt;cxxabi.h&gt;
-
-struct empty { };
-
-template &lt;typename T, int N&gt;
- struct bar { };
-
-
-int main()
-{
- int status;
- char *realname;
-
- // exception classes not in &lt;stdexcept&gt;, thrown by the implementation
- // instead of the user
- std::bad_exception e;
- realname = abi::__cxa_demangle(e.what(), 0, 0, &amp;status);
- std::cout &lt;&lt; e.what() &lt;&lt; "\t=&gt; " &lt;&lt; realname &lt;&lt; "\t: " &lt;&lt; status &lt;&lt; '\n';
- free(realname);
-
-
- // typeid
- bar&lt;empty,17&gt; u;
- const std::type_info &amp;ti = typeid(u);
-
- realname = abi::__cxa_demangle(ti.name(), 0, 0, &amp;status);
- std::cout &lt;&lt; ti.name() &lt;&lt; "\t=&gt; " &lt;&lt; realname &lt;&lt; "\t: " &lt;&lt; status &lt;&lt; '\n';
- free(realname);
-
- return 0;
-}
- </pre><p>
- This prints
- </p><pre class="screen">
- <code class="computeroutput">
- St13bad_exception =&gt; std::bad_exception : 0
- 3barI5emptyLi17EE =&gt; bar&lt;empty, 17&gt; : 0
- </code>
- </pre><p>
- The demangler interface is described in the source documentation
- linked to above. It is actually written in C, so you don't need to
- be writing C++ in order to demangle C++. (That also means we have to
- use crummy memory management facilities, so don't forget to free()
- the returned char array.)
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ext_io.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ext_concurrency.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 38. Input and Output </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 40. Concurrency</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_io.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_io.html
deleted file mode 100644
index f79e3275d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_io.html
+++ /dev/null
@@ -1,51 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 38. Input and Output</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="ext_iterators.html" title="Chapter 37. Iterators" /><link rel="next" href="ext_demangling.html" title="Chapter 39. Demangling" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 38. Input and Output</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ext_iterators.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="ext_demangling.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.io"></a>Chapter 38. Input and Output</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="ext_io.html#manual.ext.io.filebuf_derived">Derived filebufs</a></span></dt></dl></div><p>
- Extensions allowing <code class="code">filebuf</code>s to be constructed from
- "C" types like FILE*s and file descriptors.
- </p><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.io.filebuf_derived"></a>Derived filebufs</h2></div></div></div><p>The v2 library included non-standard extensions to construct
- <code class="code">std::filebuf</code>s from C stdio types such as
- <code class="code">FILE*</code>s and POSIX file descriptors.
- Today the recommended way to use stdio types with libstdc++
- IOStreams is via the <code class="code">stdio_filebuf</code> class (see below),
- but earlier releases provided slightly different mechanisms.
- </p><div class="itemizedlist"><ul type="disc"><li><p>3.0.x <code class="code">filebuf</code>s have another ctor with this signature:
- <code class="code">basic_filebuf(__c_file_type*, ios_base::openmode, int_type);
- </code>
- This comes in very handy in a number of places, such as
- attaching Unix sockets, pipes, and anything else which uses file
- descriptors, into the IOStream buffering classes. The three
- arguments are as follows:
- </p><div class="itemizedlist"><ul type="circle"><li><p><code class="code">__c_file_type* F </code>
- // the __c_file_type typedef usually boils down to stdio's FILE
- </p></li><li><p><code class="code">ios_base::openmode M </code>
- // same as all the other uses of openmode
- </p></li><li><p><code class="code">int_type B </code>
- // buffer size, defaults to BUFSIZ if not specified
- </p></li></ul></div><p>
- For those wanting to use file descriptors instead of FILE*'s, I
- invite you to contemplate the mysteries of C's <code class="code">fdopen()</code>.
- </p></li><li><p>In library snapshot 3.0.95 and later, <code class="code">filebuf</code>s bring
- back an old extension: the <code class="code">fd()</code> member function. The
- integer returned from this function can be used for whatever file
- descriptors can be used for on your platform. Naturally, the
- library cannot track what you do on your own with a file descriptor,
- so if you perform any I/O directly, don't expect the library to be
- aware of it.
- </p></li><li><p>Beginning with 3.1, the extra <code class="code">filebuf</code> constructor and
- the <code class="code">fd()</code> function were removed from the standard
- filebuf. Instead, <code class="code">&lt;ext/stdio_filebuf.h&gt;</code> contains
- a derived class called
- <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/class____gnu__cxx_1_1stdio__filebuf.html" target="_top"><code class="code">__gnu_cxx::stdio_filebuf</code></a>.
- This class can be constructed from a C <code class="code">FILE*</code> or a file
- descriptor, and provides the <code class="code">fd()</code> function.
- </p></li></ul></div><p>If you want to access a <code class="code">filebuf</code>'s file descriptor to
- implement file locking (e.g. using the <code class="code">fcntl()</code> system
- call) then you might be interested in Henry Suter's
- <a class="ulink" href="http://suter.home.cern.ch/suter/RWLock.html" target="_top">RWLock</a>
- class.
- </p><p>
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ext_iterators.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ext_demangling.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 37. Iterators </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 39. Demangling</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_iterators.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_iterators.html
deleted file mode 100644
index 130907ecb..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_iterators.html
+++ /dev/null
@@ -1,14 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 37. Iterators</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="ext_numerics.html" title="Chapter 36. Numerics" /><link rel="next" href="ext_io.html" title="Chapter 38. Input and Output" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 37. Iterators</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ext_numerics.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="ext_io.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.iterators"></a>Chapter 37. Iterators</h2></div></div></div><p>24.3.2 describes <code class="code">struct iterator</code>, which didn't exist in the
- original HP STL implementation (the language wasn't rich enough at the
- time). For backwards compatibility, base classes are provided which
- declare the same nested typedefs:
-</p><div class="itemizedlist"><ul type="disc"><li><p>input_iterator</p></li><li><p>output_iterator</p></li><li><p>forward_iterator</p></li><li><p>bidirectional_iterator</p></li><li><p>random_access_iterator</p></li></ul></div><p>24.3.4 describes iterator operation <code class="code">distance</code>, which takes
- two iterators and returns a result. It is extended by another signature
- which takes two iterators and a reference to a result. The result is
- modified, and the function returns nothing.
-</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ext_numerics.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ext_io.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 36. Numerics </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 38. Input and Output</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_numerics.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_numerics.html
deleted file mode 100644
index 437658d62..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_numerics.html
+++ /dev/null
@@ -1,20 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 36. Numerics</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="ext_algorithms.html" title="Chapter 35. Algorithms" /><link rel="next" href="ext_iterators.html" title="Chapter 37. Iterators" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 36. Numerics</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ext_algorithms.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="ext_iterators.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.numerics"></a>Chapter 36. Numerics</h2></div></div></div><p>26.4, the generalized numeric operations such as accumulate, are extended
- with the following functions:
-</p><pre class="programlisting">
- power (x, n);
- power (x, n, moniod_operation);</pre><p>Returns, in FORTRAN syntax, "x ** n" where n&gt;=0. In the
- case of n == 0, returns the <a class="ulink" href="#ch20" target="_top">identity element</a> for the
- monoid operation. The two-argument signature uses multiplication (for
- a true "power" implementation), but addition is supported as well.
- The operation functor must be associative.
-</p><p>The <code class="code">iota</code> function wins the award for Extension With the
- Coolest Name. It "assigns sequentially increasing values to a range.
- That is, it assigns value to *first, value + 1 to *(first + 1) and so
- on." Quoted from SGI documentation.
-</p><pre class="programlisting">
- void iota(_ForwardIter first, _ForwardIter last, _Tp value);</pre></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ext_algorithms.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ext_iterators.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 35. Algorithms </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 37. Iterators</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_utilities.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_utilities.html
deleted file mode 100644
index e5e50d972..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/ext_utilities.html
+++ /dev/null
@@ -1,41 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 34. Utilities</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="bk01pt12ch33s03.html" title="Deprecated HP/SGI" /><link rel="next" href="ext_algorithms.html" title="Chapter 35. Algorithms" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 34. Utilities</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch33s03.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="ext_algorithms.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.util"></a>Chapter 34. Utilities</h2></div></div></div><p>
- The &lt;functional&gt; header contains many additional functors
- and helper functions, extending section 20.3. They are
- implemented in the file stl_function.h:
- </p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">identity_element</code> for addition and multiplication. *
- </p></li><li><p>The functor <code class="code">identity</code>, whose <code class="code">operator()</code>
- returns the argument unchanged. *
- </p></li><li><p>Composition functors <code class="code">unary_function</code> and
- <code class="code">binary_function</code>, and their helpers <code class="code">compose1</code>
- and <code class="code">compose2</code>. *
- </p></li><li><p><code class="code">select1st</code> and <code class="code">select2nd</code>, to strip pairs. *
- </p></li><li><p><code class="code">project1st</code> and <code class="code">project2nd</code>. * </p></li><li><p>A set of functors/functions which always return the same result. They
- are <code class="code">constant_void_fun</code>, <code class="code">constant_binary_fun</code>,
- <code class="code">constant_unary_fun</code>, <code class="code">constant0</code>,
- <code class="code">constant1</code>, and <code class="code">constant2</code>. * </p></li><li><p>The class <code class="code">subtractive_rng</code>. * </p></li><li><p>mem_fun adaptor helpers <code class="code">mem_fun1</code> and
- <code class="code">mem_fun1_ref</code> are provided for backwards compatibility. </p></li></ul></div><p>
- 20.4.1 can use several different allocators; they are described on the
- main extensions page.
-</p><p>
- 20.4.3 is extended with a special version of
- <code class="code">get_temporary_buffer</code> taking a second argument. The
- argument is a pointer, which is ignored, but can be used to specify
- the template type (instead of using explicit function template
- arguments like the standard version does). That is, in addition to
-</p><pre class="programlisting">
-get_temporary_buffer&lt;int&gt;(5);
-</pre><p>
-you can also use
-</p><pre class="programlisting">
-get_temporary_buffer(5, (int*)0);
-</pre><p>
- A class <code class="code">temporary_buffer</code> is given in stl_tempbuf.h. *
-</p><p>
- The specialized algorithms of section 20.4.4 are extended with
- <code class="code">uninitialized_copy_n</code>. *
-</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch33s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ext_algorithms.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Deprecated HP/SGI </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 35. Algorithms</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/extensions.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/extensions.html
deleted file mode 100644
index e5171180e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/extensions.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part XII.  Extensions</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="bk01pt11ch28s02.html" title="Performance" /><link rel="next" href="bk01pt12pr03.html" title="" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part XII. 
- Extensions
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt11ch28s02.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12pr03.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.ext"></a>Part XII. 
- Extensions
- <a id="id415383" class="indexterm"></a>
-</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="bk01pt12pr03.html"></a></span></dt><dt><span class="chapter"><a href="ext_compile_checks.html">29. Compile Time Checks</a></span></dt><dt><span class="chapter"><a href="debug_mode.html">30. Debug Mode</a></span></dt><dd><dl><dt><span class="sect1"><a href="debug_mode.html#manual.ext.debug_mode.intro">Intro</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch30s02.html">Semantics</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch30s03.html">Using</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch30s03.html#debug_mode.using.mode">Using the Debug Mode</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch30s03.html#debug_mode.using.specific">Using a Specific Debug Container</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch30s04.html">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch30s04.html#manual.ext.debug_mode.design.goals">Goals</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch30s04.html#manual.ext.debug_mode.design.methods">Methods</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch30s04.html#manual.ext.debug_mode.design.other">Other Implementations</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="parallel_mode.html">31. Parallel Mode</a></span></dt><dd><dl><dt><span class="sect1"><a href="parallel_mode.html#manual.ext.parallel_mode.intro">Intro</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch31s02.html">Semantics</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch31s03.html">Using</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch31s03.html#parallel_mode.using.prereq_flags">Prerequisite Compiler Flags</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch31s03.html#parallel_mode.using.parallel_mode">Using Parallel Mode</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch31s03.html#parallel_mode.using.specific">Using Specific Parallel Components</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch31s04.html">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch31s04.html#manual.ext.parallel_mode.design.intro">Interface Basics</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch31s04.html#manual.ext.parallel_mode.design.tuning">Configuration and Tuning</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch31s04.html#manual.ext.parallel_mode.design.impl">Implementation Namespaces</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch31s05.html">Testing</a></span></dt><dt><span class="bibliography"><a href="parallel_mode.html#parallel_mode.biblio">Bibliography</a></span></dt></dl></dd><dt><span class="chapter"><a href="ext_allocators.html">32. Allocators</a></span></dt><dd><dl><dt><span class="sect1"><a href="ext_allocators.html#manual.ext.allocator.mt">mt_allocator</a></span></dt><dd><dl><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.intro">Intro</a></span></dt><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.example_single">Single Thread Example</a></span></dt><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.example_multi">Multiple Thread Example</a></span></dt></dl></dd><dt><span class="sect1"><a href="bitmap_allocator.html">bitmap_allocator</a></span></dt><dd><dl><dt><span class="sect2"><a href="bitmap_allocator.html#allocator.bitmap.design">Design</a></span></dt><dt><span class="sect2"><a href="bitmap_allocator.html#allocator.bitmap.impl">Implementation</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="ext_containers.html">33. Containers</a></span></dt><dd><dl><dt><span class="sect1"><a href="ext_containers.html#manual.ext.containers.pbds">Policy Based Data Structures</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch33s02.html">HP/SGI</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch33s03.html">Deprecated HP/SGI</a></span></dt></dl></dd><dt><span class="chapter"><a href="ext_utilities.html">34. Utilities</a></span></dt><dt><span class="chapter"><a href="ext_algorithms.html">35. Algorithms</a></span></dt><dt><span class="chapter"><a href="ext_numerics.html">36. Numerics</a></span></dt><dt><span class="chapter"><a href="ext_iterators.html">37. Iterators</a></span></dt><dt><span class="chapter"><a href="ext_io.html">38. Input and Output</a></span></dt><dd><dl><dt><span class="sect1"><a href="ext_io.html#manual.ext.io.filebuf_derived">Derived filebufs</a></span></dt></dl></dd><dt><span class="chapter"><a href="ext_demangling.html">39. Demangling</a></span></dt><dt><span class="chapter"><a href="ext_concurrency.html">40. Concurrency</a></span></dt><dd><dl><dt><span class="sect1"><a href="ext_concurrency.html#manual.ext.concurrency.design">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="ext_concurrency.html#manual.ext.concurrency.design.threads">Interface to Locks and Mutexes</a></span></dt><dt><span class="sect2"><a href="ext_concurrency.html#manual.ext.concurrency.design.atomics">Interface to Atomic Functions</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch40s02.html">Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch40s02.html#manual.ext.concurrency.impl.atomic_fallbacks">Using Builtin Atomic Functions</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch40s02.html#manual.ext.concurrency.impl.thread">Thread Abstraction</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch40s03.html">Use</a></span></dt></dl></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt11ch28s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12pr03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Performance </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/facets.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/facets.html
deleted file mode 100644
index cf2bb06b2..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/facets.html
+++ /dev/null
@@ -1,77 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 15. Facets aka Categories</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="localization.html" title="Part VI.  Localization" /><link rel="prev" href="locales.html" title="Chapter 14. Locales" /><link rel="next" href="codecvt.html" title="codecvt" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 15. Facets aka Categories</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="locales.html">Prev</a> </td><th width="60%" align="center">Part VI. 
- Localization
-
-</th><td width="20%" align="right"> <a accesskey="n" href="codecvt.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.localization.facet"></a>Chapter 15. Facets aka Categories</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="facets.html#manual.localization.facet.ctype">ctype</a></span></dt><dd><dl><dt><span class="sect2"><a href="facets.html#facet.ctype.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="facets.html#facet.ctype.future">Future</a></span></dt></dl></dd><dt><span class="sect1"><a href="codecvt.html">codecvt</a></span></dt><dd><dl><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.req">Requirements</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.design">Design</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.use">Use</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.future">Future</a></span></dt></dl></dd><dt><span class="sect1"><a href="messages.html">messages</a></span></dt><dd><dl><dt><span class="sect2"><a href="messages.html#facet.messages.req">Requirements</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.design">Design</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.use">Use</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.future">Future</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.localization.facet.ctype"></a>ctype</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.ctype.impl"></a>Implementation</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id393159"></a>Specializations</h4></div></div></div><p>
-For the required specialization codecvt&lt;wchar_t, char, mbstate_t&gt; ,
-conversions are made between the internal character set (always UCS4
-on GNU/Linux) and whatever the currently selected locale for the
-LC_CTYPE category implements.
-</p><p>
-The two required specializations are implemented as follows:
-</p><p>
-<code class="code">
-ctype&lt;char&gt;
-</code>
-</p><p>
-This is simple specialization. Implementing this was a piece of cake.
-</p><p>
-<code class="code">
-ctype&lt;wchar_t&gt;
-</code>
-</p><p>
-This specialization, by specifying all the template parameters, pretty
-much ties the hands of implementors. As such, the implementation is
-straightforward, involving mcsrtombs for the conversions between char
-to wchar_t and wcsrtombs for conversions between wchar_t and char.
-</p><p>
-Neither of these two required specializations deals with Unicode
-characters.
-</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.ctype.future"></a>Future</h3></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
- How to deal with the global locale issue?
- </p></li><li><p>
- How to deal with different types than char, wchar_t? </p></li><li><p>
- Overlap between codecvt/ctype: narrow/widen
- </p></li><li><p>
- Mask typedef in codecvt_base, argument types in codecvt. what
- is know about this type?
- </p></li><li><p>
- Why mask* argument in codecvt?
- </p></li><li><p>
- Can this be made (more) generic? is there a simple way to
- straighten out the configure-time mess that is a by-product of
- this class?
- </p></li><li><p>
- Get the ctype&lt;wchar_t&gt;::mask stuff under control. Need to
- make some kind of static table, and not do lookup every time
- somebody hits the do_is... functions. Too bad we can't just
- redefine mask for ctype&lt;wchar_t&gt;
- </p></li><li><p>
- Rename abstract base class. See if just smash-overriding is a
- better approach. Clarify, add sanity to naming.
- </p></li></ul></div></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="facet.ctype.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id471356"></a><p><span class="title"><i>
- The GNU C Library
- </i>. </span><span class="author"><span class="firstname">Roland</span> <span class="surname">McGrath</span>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2007 FSF. </span><span class="pagenums">Chapters 6 Character Set Handling and 7 Locales and Internationalization. </span></p></div><div class="biblioentry"><a id="id413436"></a><p><span class="title"><i>
- Correspondence
- </i>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2002 . </span></p></div><div class="biblioentry"><a id="id424158"></a><p><span class="title"><i>
- ISO/IEC 14882:1998 Programming languages - C++
- </i>. </span><span class="copyright">Copyright © 1998 ISO. </span></p></div><div class="biblioentry"><a id="id424176"></a><p><span class="title"><i>
- ISO/IEC 9899:1999 Programming languages - C
- </i>. </span><span class="copyright">Copyright © 1999 ISO. </span></p></div><div class="biblioentry"><a id="id461050"></a><p><span class="title"><i>
- System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x)
- </i>. </span><span class="copyright">Copyright © 1999
- The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. </span><span class="biblioid">
- <a class="ulink" href="http://www.opennc.org/austin/docreg.html" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id461076"></a><p><span class="title"><i>
- The C++ Programming Language, Special Edition
- </i>. </span><span class="author"><span class="firstname">Bjarne</span> <span class="surname">Stroustrup</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley, Inc.. </span><span class="pagenums">Appendix D. </span><span class="publisher"><span class="publishername">
- Addison Wesley
- . </span></span></p></div><div class="biblioentry"><a id="id426264"></a><p><span class="title"><i>
- Standard C++ IOStreams and Locales
- </i>. </span><span class="subtitle">
- Advanced Programmer's Guide and Reference
- . </span><span class="author"><span class="firstname">Angelika</span> <span class="surname">Langer</span>. </span><span class="author"><span class="firstname">Klaus</span> <span class="surname">Kreft</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley Longman, Inc.. </span><span class="publisher"><span class="publishername">
- Addison Wesley Longman
- . </span></span></p></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="locales.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="localization.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="codecvt.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 14. Locales </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> codecvt</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/fstreams.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/fstreams.html
deleted file mode 100644
index aaa0c88f9..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/fstreams.html
+++ /dev/null
@@ -1,52 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 27. File Based Streams</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="io.html" title="Part XI.  Input and Output" /><link rel="prev" href="stringstreams.html" title="Chapter 26. Memory Based Streams" /><link rel="next" href="bk01pt11ch27s02.html" title="Binary Input and Output" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 27. File Based Streams</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="stringstreams.html">Prev</a> </td><th width="60%" align="center">Part XI. 
- Input and Output
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt11ch27s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.io.filestreams"></a>Chapter 27. File Based Streams</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="fstreams.html#manual.io.filestreams.copying_a_file">Copying a File</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch27s02.html">Binary Input and Output</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch27s03.html">More Binary Input and Output</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.io.filestreams.copying_a_file"></a>Copying a File</h2></div></div></div><p>
- </p><p>So you want to copy a file quickly and easily, and most important,
- completely portably. And since this is C++, you have an open
- ifstream (call it IN) and an open ofstream (call it OUT):
- </p><pre class="programlisting">
- #include &lt;fstream&gt;
-
- std::ifstream IN ("input_file");
- std::ofstream OUT ("output_file"); </pre><p>Here's the easiest way to get it completely wrong:
- </p><pre class="programlisting">
- OUT &lt;&lt; IN;</pre><p>For those of you who don't already know why this doesn't work
- (probably from having done it before), I invite you to quickly
- create a simple text file called "input_file" containing
- the sentence
- </p><pre class="programlisting">
- The quick brown fox jumped over the lazy dog.</pre><p>surrounded by blank lines. Code it up and try it. The contents
- of "output_file" may surprise you.
- </p><p>Seriously, go do it. Get surprised, then come back. It's worth it.
- </p><p>The thing to remember is that the <code class="code">basic_[io]stream</code> classes
- handle formatting, nothing else. In particular, they break up on
- whitespace. The actual reading, writing, and storing of data is
- handled by the <code class="code">basic_streambuf</code> family. Fortunately, the
- <code class="code">operator&lt;&lt;</code> is overloaded to take an ostream and
- a pointer-to-streambuf, in order to help with just this kind of
- "dump the data verbatim" situation.
- </p><p>Why a <span class="emphasis"><em>pointer</em></span> to streambuf and not just a streambuf? Well,
- the [io]streams hold pointers (or references, depending on the
- implementation) to their buffers, not the actual
- buffers. This allows polymorphic behavior on the part of the buffers
- as well as the streams themselves. The pointer is easily retrieved
- using the <code class="code">rdbuf()</code> member function. Therefore, the easiest
- way to copy the file is:
- </p><pre class="programlisting">
- OUT &lt;&lt; IN.rdbuf();</pre><p>So what <span class="emphasis"><em>was</em></span> happening with OUT&lt;&lt;IN? Undefined
- behavior, since that particular &lt;&lt; isn't defined by the Standard.
- I have seen instances where it is implemented, but the character
- extraction process removes all the whitespace, leaving you with no
- blank lines and only "Thequickbrownfox...". With
- libraries that do not define that operator, IN (or one of IN's
- member pointers) sometimes gets converted to a void*, and the output
- file then contains a perfect text representation of a hexadecimal
- address (quite a big surprise). Others don't compile at all.
- </p><p>Also note that none of this is specific to o<span class="emphasis"><em>*f*</em></span>streams.
- The operators shown above are all defined in the parent
- basic_ostream class and are therefore available with all possible
- descendants.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="stringstreams.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="io.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt11ch27s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 26. Memory Based Streams </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Binary Input and Output</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/functors.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/functors.html
deleted file mode 100644
index 7eed8c4b3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/functors.html
+++ /dev/null
@@ -1,15 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 9. Functors</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="utilities.html" title="Part IV.  Utilities" /><link rel="prev" href="utilities.html" title="Part IV.  Utilities" /><link rel="next" href="pairs.html" title="Chapter 10. Pairs" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 9. Functors</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="utilities.html">Prev</a> </td><th width="60%" align="center">Part IV. 
- Utilities
-
-</th><td width="20%" align="right"> <a accesskey="n" href="pairs.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.util.functors"></a>Chapter 9. Functors</h2></div></div></div><p>If you don't know what functors are, you're not alone. Many people
- get slightly the wrong idea. In the interest of not reinventing
- the wheel, we will refer you to the introduction to the functor
- concept written by SGI as part of their STL, in
- <a class="ulink" href="http://www.sgi.com/tech/stl/functors.html" target="_top">their
- http://www.sgi.com/tech/stl/functors.html</a>.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="utilities.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="utilities.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="pairs.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part IV. 
- Utilities
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 10. Pairs</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/fundamental_types.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/fundamental_types.html
deleted file mode 100644
index e1afd2eb3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/fundamental_types.html
+++ /dev/null
@@ -1,43 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 4. Types</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="support.html" title="Part II.  Support" /><link rel="prev" href="bk01pt02pr01.html" title="" /><link rel="next" href="bk01pt02ch04s02.html" title="Numeric Properties" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 4. Types</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt02pr01.html">Prev</a> </td><th width="60%" align="center">Part II. 
- Support
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt02ch04s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.support.types"></a>Chapter 4. Types</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="fundamental_types.html#manual.support.types.fundamental">Fundamental Types</a></span></dt><dt><span class="sect1"><a href="bk01pt02ch04s02.html">Numeric Properties</a></span></dt><dt><span class="sect1"><a href="bk01pt02ch04s03.html">NULL</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.support.types.fundamental"></a>Fundamental Types</h2></div></div></div><p>
- C++ has the following builtin types:
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- char
- </p></li><li><p>
- signed char
- </p></li><li><p>
- unsigned char
- </p></li><li><p>
- signed short
- </p></li><li><p>
- signed int
- </p></li><li><p>
- signed long
- </p></li><li><p>
- unsigned short
- </p></li><li><p>
- unsigned int
- </p></li><li><p>
- unsigned long
- </p></li><li><p>
- bool
- </p></li><li><p>
- wchar_t
- </p></li><li><p>
- float
- </p></li><li><p>
- double
- </p></li><li><p>
- long double
- </p></li></ul></div><p>
- These fundamental types are always available, without having to
- include a header file. These types are exactly the same in
- either C++ or in C.
- </p><p>
- Specializing parts of the library on these types is prohibited:
- instead, use a POD.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt02pr01.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="support.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt02ch04s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Numeric Properties</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/generalized_numeric_operations.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/generalized_numeric_operations.html
deleted file mode 100644
index d925b093d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/generalized_numeric_operations.html
+++ /dev/null
@@ -1,29 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 22. Generalized Operations</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="numerics.html" title="Part X.  Numerics" /><link rel="prev" href="complex.html" title="Chapter 21. Complex" /><link rel="next" href="numerics_and_c.html" title="Chapter 23. Interacting with C" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 22. Generalized Operations</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="complex.html">Prev</a> </td><th width="60%" align="center">Part X. 
- Numerics
-
-</th><td width="20%" align="right"> <a accesskey="n" href="numerics_and_c.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.numerics.generalized_ops"></a>Chapter 22. Generalized Operations</h2></div></div></div><p>
- </p><p>There are four generalized functions in the &lt;numeric&gt; header
- that follow the same conventions as those in &lt;algorithm&gt;. Each
- of them is overloaded: one signature for common default operations,
- and a second for fully general operations. Their names are
- self-explanatory to anyone who works with numerics on a regular basis:
- </p><div class="itemizedlist"><ul type="disc"><li><p><code class="code">accumulate</code></p></li><li><p><code class="code">inner_product</code></p></li><li><p><code class="code">partial_sum</code></p></li><li><p><code class="code">adjacent_difference</code></p></li></ul></div><p>Here is a simple example of the two forms of <code class="code">accumulate</code>.
- </p><pre class="programlisting">
- int ar[50];
- int someval = somefunction();
-
- // ...initialize members of ar to something...
-
- int sum = std::accumulate(ar,ar+50,0);
- int sum_stuff = std::accumulate(ar,ar+50,someval);
- int product = std::accumulate(ar,ar+50,1,std::multiplies&lt;int&gt;());
- </pre><p>The first call adds all the members of the array, using zero as an
- initial value for <code class="code">sum</code>. The second does the same, but uses
- <code class="code">someval</code> as the starting value (thus, <code class="code">sum_stuff == sum +
- someval</code>). The final call uses the second of the two signatures,
- and multiplies all the members of the array; here we must obviously
- use 1 as a starting value instead of 0.
- </p><p>The other three functions have similar dual-signature forms.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="complex.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="numerics.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="numerics_and_c.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 21. Complex </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 23. Interacting with C</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/internals.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/internals.html
deleted file mode 100644
index 61defdc84..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/internals.html
+++ /dev/null
@@ -1,374 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Porting to New Hardware or Operating Systems</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; internals&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_porting.html" title="Appendix B.  Porting and Maintenance" /><link rel="prev" href="appendix_porting.html" title="Appendix B.  Porting and Maintenance" /><link rel="next" href="abi.html" title="ABI Policy and Guidelines" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Porting to New Hardware or Operating Systems</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="appendix_porting.html">Prev</a> </td><th width="60%" align="center">Appendix B. 
- Porting and Maintenance
-
-</th><td width="20%" align="right"> <a accesskey="n" href="abi.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="appendix.porting.internals"></a>Porting to New Hardware or Operating Systems</h2></div></div></div><p>
-</p><p>This document explains how to port libstdc++ (the GNU C++ library) to
-a new target.
-</p><p>In order to make the GNU C++ library (libstdc++) work with a new
-target, you must edit some configuration files and provide some new
-header files. Unless this is done, libstdc++ will use generic
-settings which may not be correct for your target; even if they are
-correct, they will likely be inefficient.
- </p><p>Before you get started, make sure that you have a working C library on
-your target. The C library need not precisely comply with any
-particular standard, but should generally conform to the requirements
-imposed by the ANSI/ISO standard.
- </p><p>In addition, you should try to verify that the C++ compiler generally
-works. It is difficult to test the C++ compiler without a working
-library, but you should at least try some minimal test cases.
- </p><p>(Note that what we think of as a "target," the library refers to as
-a "host." The comment at the top of <code class="code">configure.ac</code> explains why.)
- </p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="internals.os"></a>Operating System</h3></div></div></div><p>If you are porting to a new operating system (as opposed to a new chip
-using an existing operating system), you will need to create a new
-directory in the <code class="code">config/os</code> hierarchy. For example, the IRIX
-configuration files are all in <code class="code">config/os/irix</code>. There is no set
-way to organize the OS configuration directory. For example,
-<code class="code">config/os/solaris/solaris-2.6</code> and
-<code class="code">config/os/solaris/solaris-2.7</code> are used as configuration
-directories for these two versions of Solaris. On the other hand, both
-Solaris 2.7 and Solaris 2.8 use the <code class="code">config/os/solaris/solaris-2.7</code>
-directory. The important information is that there needs to be a
-directory under <code class="code">config/os</code> to store the files for your operating
-system.
-</p><p>You might have to change the <code class="code">configure.host</code> file to ensure that
-your new directory is activated. Look for the switch statement that sets
-<code class="code">os_include_dir</code>, and add a pattern to handle your operating system
-if the default will not suffice. The switch statement switches on only
-the OS portion of the standard target triplet; e.g., the <code class="code">solaris2.8</code>
-in <code class="code">sparc-sun-solaris2.8</code>. If the new directory is named after the
-OS portion of the triplet (the default), then nothing needs to be changed.
- </p><p>The first file to create in this directory, should be called
-<code class="code">os_defines.h</code>. This file contains basic macro definitions
-that are required to allow the C++ library to work with your C library.
- </p><p>Several libstdc++ source files unconditionally define the macro
-<code class="code">_POSIX_SOURCE</code>. On many systems, defining this macro causes
-large portions of the C library header files to be eliminated
-at preprocessing time. Therefore, you may have to <code class="code">#undef</code> this
-macro, or define other macros (like <code class="code">_LARGEFILE_SOURCE</code> or
-<code class="code">__EXTENSIONS__</code>). You won't know what macros to define or
-undefine at this point; you'll have to try compiling the library and
-seeing what goes wrong. If you see errors about calling functions
-that have not been declared, look in your C library headers to see if
-the functions are declared there, and then figure out what macros you
-need to define. You will need to add them to the
-<code class="code">CPLUSPLUS_CPP_SPEC</code> macro in the GCC configuration file for your
-target. It will not work to simply define these macros in
-<code class="code">os_defines.h</code>.
- </p><p>At this time, there are a few libstdc++-specific macros which may be
-defined:
- </p><p><code class="code">_GLIBCXX_USE_C99_CHECK</code> may be defined to 1 to check C99
-function declarations (which are not covered by specialization below)
-found in system headers against versions found in the library headers
-derived from the standard.
- </p><p><code class="code">_GLIBCXX_USE_C99_DYNAMIC</code> may be defined to an expression that
-yields 0 if and only if the system headers are exposing proper support
-for C99 functions (which are not covered by specialization below). If
-defined, it must be 0 while bootstrapping the compiler/rebuilding the
-library.
- </p><p><code class="code">_GLIBCXX_USE_C99_LONG_LONG_CHECK</code> may be defined to 1 to check
-the set of C99 long long function declarations found in system headers
-against versions found in the library headers derived from the
-standard.
-
- </p><p><code class="code">_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC</code> may be defined to an
-expression that yields 0 if and only if the system headers are
-exposing proper support for the set of C99 long long functions. If
-defined, it must be 0 while bootstrapping the compiler/rebuilding the
-library.
- </p><p><code class="code">_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC</code> may be defined to an
-expression that yields 0 if and only if the system headers
-are exposing proper support for the related set of macros. If defined,
-it must be 0 while bootstrapping the compiler/rebuilding the library.
- </p><p><code class="code">_GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK</code> may be defined
-to 1 to check the related set of function declarations found in system
-headers against versions found in the library headers derived from
-the standard.
- </p><p><code class="code">_GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC</code> may be defined
-to an expression that yields 0 if and only if the system headers
-are exposing proper support for the related set of functions. If defined,
-it must be 0 while bootstrapping the compiler/rebuilding the library.
- </p><p>Finally, you should bracket the entire file in an include-guard, like
-this:
- </p><pre class="programlisting">
-
-#ifndef _GLIBCXX_OS_DEFINES
-#define _GLIBCXX_OS_DEFINES
-...
-#endif
-</pre><p>We recommend copying an existing <code class="code">os_defines.h</code> to use as a
-starting point.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="internals.cpu"></a>CPU</h3></div></div></div><p>If you are porting to a new chip (as opposed to a new operating system
-running on an existing chip), you will need to create a new directory in the
-<code class="code">config/cpu</code> hierarchy. Much like the <a class="link" href="internals.html#internals.os" title="Operating System">Operating system</a> setup,
-there are no strict rules on how to organize the CPU configuration
-directory, but careful naming choices will allow the configury to find your
-setup files without explicit help.
-</p><p>We recommend that for a target triplet <code class="code">&lt;CPU&gt;-&lt;vendor&gt;-&lt;OS&gt;</code>, you
-name your configuration directory <code class="code">config/cpu/&lt;CPU&gt;</code>. If you do this,
-the configury will find the directory by itself. Otherwise you will need to
-edit the <code class="code">configure.host</code> file and, in the switch statement that sets
-<code class="code">cpu_include_dir</code>, add a pattern to handle your chip.
- </p><p>Note that some chip families share a single configuration directory, for
-example, <code class="code">alpha</code>, <code class="code">alphaev5</code>, and <code class="code">alphaev6</code> all use the
-<code class="code">config/cpu/alpha</code> directory, and there is an entry in the
-<code class="code">configure.host</code> switch statement to handle this.
- </p><p>The <code class="code">cpu_include_dir</code> sets default locations for the files controlling
-<a class="link" href="internals.html#internals.thread_safety" title="Thread Safety">Thread safety</a> and <a class="link" href="internals.html#internals.numeric_limits" title="Numeric Limits">Numeric limits</a>, if the defaults are not
-appropriate for your chip.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="internals.char_types"></a>Character Types</h3></div></div></div><p>The library requires that you provide three header files to implement
-character classification, analogous to that provided by the C libraries
-<code class="code">&lt;ctype.h&gt;</code> header. You can model these on the files provided in
-<code class="code">config/os/generic</code>. However, these files will almost
-certainly need some modification.
-</p><p>The first file to write is <code class="code">ctype_base.h</code>. This file provides
-some very basic information about character classification. The libstdc++
-library assumes that your C library implements <code class="code">&lt;ctype.h&gt;</code> by using
-a table (indexed by character code) containing integers, where each of
-these integers is a bit-mask indicating whether the character is
-upper-case, lower-case, alphabetic, etc. The <code class="code">ctype_base.h</code>
-file gives the type of the integer, and the values of the various bit
-masks. You will have to peer at your own <code class="code">&lt;ctype.h&gt;</code> to figure out
-how to define the values required by this file.
- </p><p>The <code class="code">ctype_base.h</code> header file does not need include guards.
-It should contain a single <code class="code">struct</code> definition called
-<code class="code">ctype_base</code>. This <code class="code">struct</code> should contain two type
-declarations, and one enumeration declaration, like this example, taken
-from the IRIX configuration:
- </p><pre class="programlisting">
- struct ctype_base
- {
- typedef unsigned int mask;
- typedef int* __to_type;
-
- enum
- {
- space = _ISspace,
- print = _ISprint,
- cntrl = _IScntrl,
- upper = _ISupper,
- lower = _ISlower,
- alpha = _ISalpha,
- digit = _ISdigit,
- punct = _ISpunct,
- xdigit = _ISxdigit,
- alnum = _ISalnum,
- graph = _ISgraph
- };
- };
-</pre><p>The <code class="code">mask</code> type is the type of the elements in the table. If your
-C library uses a table to map lower-case numbers to upper-case numbers,
-and vice versa, you should define <code class="code">__to_type</code> to be the type of the
-elements in that table. If you don't mind taking a minor performance
-penalty, or if your library doesn't implement <code class="code">toupper</code> and
-<code class="code">tolower</code> in this way, you can pick any pointer-to-integer type,
-but you must still define the type.
-</p><p>The enumeration should give definitions for all the values in the above
-example, using the values from your native <code class="code">&lt;ctype.h&gt;</code>. They can
-be given symbolically (as above), or numerically, if you prefer. You do
-not have to include <code class="code">&lt;ctype.h&gt;</code> in this header; it will always be
-included before <code class="code">ctype_base.h</code> is included.
- </p><p>The next file to write is <code class="code">ctype_noninline.h</code>, which also does
-not require include guards. This file defines a few member functions
-that will be included in <code class="code">include/bits/locale_facets.h</code>. The first
-function that must be written is the <code class="code">ctype&lt;char&gt;::ctype</code>
-constructor. Here is the IRIX example:
- </p><pre class="programlisting">
-ctype&lt;char&gt;::ctype(const mask* __table = 0, bool __del = false,
- size_t __refs = 0)
- : _Ctype_nois&lt;char&gt;(__refs), _M_del(__table != 0 &amp;&amp; __del),
- _M_toupper(NULL),
- _M_tolower(NULL),
- _M_ctable(NULL),
- _M_table(!__table
- ? (const mask*) (__libc_attr._ctype_tbl-&gt;_class + 1)
- : __table)
- { }
-</pre><p>There are two parts of this that you might choose to alter. The first,
-and most important, is the line involving <code class="code">__libc_attr</code>. That is
-IRIX system-dependent code that gets the base of the table mapping
-character codes to attributes. You need to substitute code that obtains
-the address of this table on your system. If you want to use your
-operating system's tables to map upper-case letters to lower-case, and
-vice versa, you should initialize <code class="code">_M_toupper</code> and
-<code class="code">_M_tolower</code> with those tables, in similar fashion.
-</p><p>Now, you have to write two functions to convert from upper-case to
-lower-case, and vice versa. Here are the IRIX versions:
- </p><pre class="programlisting">
- char
- ctype&lt;char&gt;::do_toupper(char __c) const
- { return _toupper(__c); }
-
- char
- ctype&lt;char&gt;::do_tolower(char __c) const
- { return _tolower(__c); }
-</pre><p>Your C library provides equivalents to IRIX's <code class="code">_toupper</code> and
-<code class="code">_tolower</code>. If you initialized <code class="code">_M_toupper</code> and
-<code class="code">_M_tolower</code> above, then you could use those tables instead.
-</p><p>Finally, you have to provide two utility functions that convert strings
-of characters. The versions provided here will always work - but you
-could use specialized routines for greater performance if you have
-machinery to do that on your system:
- </p><pre class="programlisting">
- const char*
- ctype&lt;char&gt;::do_toupper(char* __low, const char* __high) const
- {
- while (__low &lt; __high)
- {
- *__low = do_toupper(*__low);
- ++__low;
- }
- return __high;
- }
-
- const char*
- ctype&lt;char&gt;::do_tolower(char* __low, const char* __high) const
- {
- while (__low &lt; __high)
- {
- *__low = do_tolower(*__low);
- ++__low;
- }
- return __high;
- }
-</pre><p>You must also provide the <code class="code">ctype_inline.h</code> file, which
-contains a few more functions. On most systems, you can just copy
-<code class="code">config/os/generic/ctype_inline.h</code> and use it on your system.
- </p><p>In detail, the functions provided test characters for particular
-properties; they are analogous to the functions like <code class="code">isalpha</code> and
-<code class="code">islower</code> provided by the C library.
- </p><p>The first function is implemented like this on IRIX:
- </p><pre class="programlisting">
- bool
- ctype&lt;char&gt;::
- is(mask __m, char __c) const throw()
- { return (_M_table)[(unsigned char)(__c)] &amp; __m; }
-</pre><p>The <code class="code">_M_table</code> is the table passed in above, in the constructor.
-This is the table that contains the bitmasks for each character. The
-implementation here should work on all systems.
-</p><p>The next function is:
- </p><pre class="programlisting">
- const char*
- ctype&lt;char&gt;::
- is(const char* __low, const char* __high, mask* __vec) const throw()
- {
- while (__low &lt; __high)
- *__vec++ = (_M_table)[(unsigned char)(*__low++)];
- return __high;
- }
-</pre><p>This function is similar; it copies the masks for all the characters
-from <code class="code">__low</code> up until <code class="code">__high</code> into the vector given by
-<code class="code">__vec</code>.
-</p><p>The last two functions again are entirely generic:
- </p><pre class="programlisting">
- const char*
- ctype&lt;char&gt;::
- scan_is(mask __m, const char* __low, const char* __high) const throw()
- {
- while (__low &lt; __high &amp;&amp; !this-&gt;is(__m, *__low))
- ++__low;
- return __low;
- }
-
- const char*
- ctype&lt;char&gt;::
- scan_not(mask __m, const char* __low, const char* __high) const throw()
- {
- while (__low &lt; __high &amp;&amp; this-&gt;is(__m, *__low))
- ++__low;
- return __low;
- }
-</pre></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="internals.thread_safety"></a>Thread Safety</h3></div></div></div><p>The C++ library string functionality requires a couple of atomic
-operations to provide thread-safety. If you don't take any special
-action, the library will use stub versions of these functions that are
-not thread-safe. They will work fine, unless your applications are
-multi-threaded.
-</p><p>If you want to provide custom, safe, versions of these functions, there
-are two distinct approaches. One is to provide a version for your CPU,
-using assembly language constructs. The other is to use the
-thread-safety primitives in your operating system. In either case, you
-make a file called <code class="code">atomicity.h</code>, and the variable
-<code class="code">ATOMICITYH</code> must point to this file.
- </p><p>If you are using the assembly-language approach, put this code in
-<code class="code">config/cpu/&lt;chip&gt;/atomicity.h</code>, where chip is the name of
-your processor (see <a class="link" href="internals.html#internals.cpu" title="CPU">CPU</a>). No additional changes are necessary to
-locate the file in this case; <code class="code">ATOMICITYH</code> will be set by default.
- </p><p>If you are using the operating system thread-safety primitives approach,
-you can also put this code in the same CPU directory, in which case no more
-work is needed to locate the file. For examples of this approach,
-see the <code class="code">atomicity.h</code> file for IRIX or IA64.
- </p><p>Alternatively, if the primitives are more closely related to the OS
-than they are to the CPU, you can put the <code class="code">atomicity.h</code> file in
-the <a class="link" href="internals.html#internals.os" title="Operating System">Operating system</a> directory instead. In this case, you must
-edit <code class="code">configure.host</code>, and in the switch statement that handles
-operating systems, override the <code class="code">ATOMICITYH</code> variable to point to
-the appropriate <code class="code">os_include_dir</code>. For examples of this approach,
-see the <code class="code">atomicity.h</code> file for AIX.
- </p><p>With those bits out of the way, you have to actually write
-<code class="code">atomicity.h</code> itself. This file should be wrapped in an
-include guard named <code class="code">_GLIBCXX_ATOMICITY_H</code>. It should define one
-type, and two functions.
- </p><p>The type is <code class="code">_Atomic_word</code>. Here is the version used on IRIX:
- </p><pre class="programlisting">
-typedef long _Atomic_word;
-</pre><p>This type must be a signed integral type supporting atomic operations.
-If you're using the OS approach, use the same type used by your system's
-primitives. Otherwise, use the type for which your CPU provides atomic
-primitives.
-</p><p>Then, you must provide two functions. The bodies of these functions
-must be equivalent to those provided here, but using atomic operations:
- </p><pre class="programlisting">
- static inline _Atomic_word
- __attribute__ ((__unused__))
- __exchange_and_add (_Atomic_word* __mem, int __val)
- {
- _Atomic_word __result = *__mem;
- *__mem += __val;
- return __result;
- }
-
- static inline void
- __attribute__ ((__unused__))
- __atomic_add (_Atomic_word* __mem, int __val)
- {
- *__mem += __val;
- }
-</pre></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="internals.numeric_limits"></a>Numeric Limits</h3></div></div></div><p>The C++ library requires information about the fundamental data types,
-such as the minimum and maximum representable values of each type.
-You can define each of these values individually, but it is usually
-easiest just to indicate how many bits are used in each of the data
-types and let the library do the rest. For information about the
-macros to define, see the top of <code class="code">include/bits/std_limits.h</code>.
-</p><p>If you need to define any macros, you can do so in <code class="code">os_defines.h</code>.
-However, if all operating systems for your CPU are likely to use the
-same values, you can provide a CPU-specific file instead so that you
-do not have to provide the same definitions for each operating system.
-To take that approach, create a new file called <code class="code">cpu_limits.h</code> in
-your CPU configuration directory (see <a class="link" href="internals.html#internals.cpu" title="CPU">CPU</a>).
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="internals.libtool"></a>Libtool</h3></div></div></div><p>The C++ library is compiled, archived and linked with libtool.
-Explaining the full workings of libtool is beyond the scope of this
-document, but there are a few, particular bits that are necessary for
-porting.
-</p><p>Some parts of the libstdc++ library are compiled with the libtool
-<code class="code">--tags CXX</code> option (the C++ definitions for libtool). Therefore,
-<code class="code">ltcf-cxx.sh</code> in the top-level directory needs to have the correct
-logic to compile and archive objects equivalent to the C version of libtool,
-<code class="code">ltcf-c.sh</code>. Some libtool targets have definitions for C but not
-for C++, or C++ definitions which have not been kept up to date.
- </p><p>The C++ run-time library contains initialization code that needs to be
-run as the library is loaded. Often, that requires linking in special
-object files when the C++ library is built as a shared library, or
-taking other system-specific actions.
- </p><p>The libstdc++ library is linked with the C version of libtool, even
-though it is a C++ library. Therefore, the C version of libtool needs to
-ensure that the run-time library initializers are run. The usual way to
-do this is to build the library using <code class="code">gcc -shared</code>.
- </p><p>If you need to change how the library is linked, look at
-<code class="code">ltcf-c.sh</code> in the top-level directory. Find the switch statement
-that sets <code class="code">archive_cmds</code>. Here, adjust the setting for your
-operating system.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="appendix_porting.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_porting.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="abi.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Appendix B. 
- Porting and Maintenance
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> ABI Policy and Guidelines</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/intro.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/intro.html
deleted file mode 100644
index e48627083..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/intro.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part I.  Introduction</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="spine.html" title="The GNU C++ Library" /><link rel="next" href="status.html" title="Chapter 1. Status" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part I. 
- Introduction
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="spine.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="status.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.intro"></a>Part I. 
- Introduction
- <a id="id485466" class="indexterm"></a>
-</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="status.html">1. Status</a></span></dt><dd><dl><dt><span class="sect1"><a href="status.html#manual.intro.status.standard">Implementation Status</a></span></dt><dd><dl><dt><span class="sect2"><a href="status.html#manual.intro.status.standard.1998">C++ 1998/2003</a></span></dt><dt><span class="sect2"><a href="status.html#manual.intro.status.standard.tr1">C++ TR1</a></span></dt><dt><span class="sect2"><a href="status.html#manual.intro.status.standard.200x">C++ 200x</a></span></dt></dl></dd><dt><span class="sect1"><a href="license.html">License</a></span></dt><dd><dl><dt><span class="sect2"><a href="license.html#manual.intro.status.license.gpl">The Code: GPL</a></span></dt><dt><span class="sect2"><a href="license.html#manual.intro.status.license.fdl">The Documentation: GPL, FDL</a></span></dt></dl></dd><dt><span class="sect1"><a href="bugs.html">Bugs</a></span></dt><dd><dl><dt><span class="sect2"><a href="bugs.html#manual.intro.status.bugs.impl">Implementation Bugs</a></span></dt><dt><span class="sect2"><a href="bugs.html#manual.intro.status.bugs.iso">Standard Bugs</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="setup.html">2. Setup</a></span></dt><dd><dl><dt><span class="sect1"><a href="setup.html#manual.intro.setup.prereq">Prerequisites</a></span></dt><dt><span class="sect1"><a href="configure.html">Configure</a></span></dt><dt><span class="sect1"><a href="make.html">Make</a></span></dt><dt><span class="sect1"><a href="test.html">Test</a></span></dt><dd><dl><dt><span class="sect2"><a href="test.html#test.organization">Organization</a></span></dt><dt><span class="sect2"><a href="test.html#test.run">Running the Testsuite</a></span></dt><dt><span class="sect2"><a href="test.html#test.new_tests">Writing a new test case</a></span></dt><dt><span class="sect2"><a href="test.html#test.harness">Test Harness and Utilities</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="using.html">3. Using</a></span></dt><dd><dl><dt><span class="sect1"><a href="using.html#manual.intro.using.lib">Linking Library Binary Files</a></span></dt><dt><span class="sect1"><a href="using_headers.html">Headers</a></span></dt><dd><dl><dt><span class="sect2"><a href="using_headers.html#manual.intro.using.headers.all">Header Files</a></span></dt><dt><span class="sect2"><a href="using_headers.html#manual.intro.using.headers.mixing">Mixing Headers</a></span></dt><dt><span class="sect2"><a href="using_headers.html#manual.intro.using.headers.cheaders">The C Headers and namespace std</a></span></dt><dt><span class="sect2"><a href="using_headers.html#manual.intro.using.headers.pre">Precompiled Headers</a></span></dt></dl></dd><dt><span class="sect1"><a href="using_namespaces.html">Namespaces</a></span></dt><dd><dl><dt><span class="sect2"><a href="using_namespaces.html#manual.intro.using.namespaces.all">Available Namespaces</a></span></dt><dt><span class="sect2"><a href="using_namespaces.html#manual.intro.using.namespaces.std">namespace std</a></span></dt><dt><span class="sect2"><a href="using_namespaces.html#manual.intro.using.namespaces.comp">Using Namespace Composition</a></span></dt></dl></dd><dt><span class="sect1"><a href="using_macros.html">Macros</a></span></dt><dt><span class="sect1"><a href="using_concurrency.html">Concurrency</a></span></dt><dd><dl><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.prereq">Prerequisites</a></span></dt><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.thread_safety">Thread Safety</a></span></dt><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.atomics">Atomics</a></span></dt><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.io">IO</a></span></dt><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.containers">Containers</a></span></dt></dl></dd><dt><span class="sect1"><a href="using_exceptions.html">Exceptions</a></span></dt><dd><dl><dt><span class="sect2"><a href="using_exceptions.html#intro.using.exception.propagating">Propagating Exceptions aka Exception Neutrality</a></span></dt><dt><span class="sect2"><a href="using_exceptions.html#intro.using.exception.safety">Exception Safety</a></span></dt><dt><span class="sect2"><a href="using_exceptions.html#intro.using.exception.no">Support for -fno-exceptions</a></span></dt></dl></dd><dt><span class="sect1"><a href="debug.html">Debugging Support</a></span></dt><dd><dl><dt><span class="sect2"><a href="debug.html#debug.compiler">Using g++</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.req">Debug Versions of Library Binary Files</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.memory">Memory Leak Hunting</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.gdb">Using gdb</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.exceptions">Tracking uncaught exceptions</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.debug_mode">Debug Mode</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.compile_time_checks">Compile Time Checking</a></span></dt></dl></dd></dl></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="spine.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="status.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">The GNU C++ Library </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 1. Status</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/io.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/io.html
deleted file mode 100644
index c106e6475..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/io.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part XI.  Input and Output</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="bk01pt10ch23s02.html" title="C99" /><link rel="next" href="iostream_objects.html" title="Chapter 24. Iostream Objects" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part XI. 
- Input and Output
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt10ch23s02.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="iostream_objects.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.io"></a>Part XI. 
- Input and Output
- <a id="id521196" class="indexterm"></a>
-</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="iostream_objects.html">24. Iostream Objects</a></span></dt><dt><span class="chapter"><a href="streambufs.html">25. Stream Buffers</a></span></dt><dd><dl><dt><span class="sect1"><a href="streambufs.html#io.streambuf.derived">Derived streambuf Classes</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch25s02.html">Buffering</a></span></dt></dl></dd><dt><span class="chapter"><a href="stringstreams.html">26. Memory Based Streams</a></span></dt><dd><dl><dt><span class="sect1"><a href="stringstreams.html#manual.io.memstreams.compat">Compatibility With strstream</a></span></dt></dl></dd><dt><span class="chapter"><a href="fstreams.html">27. File Based Streams</a></span></dt><dd><dl><dt><span class="sect1"><a href="fstreams.html#manual.io.filestreams.copying_a_file">Copying a File</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch27s02.html">Binary Input and Output</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch27s03.html">More Binary Input and Output</a></span></dt></dl></dd><dt><span class="chapter"><a href="io_and_c.html">28. Interacting with C</a></span></dt><dd><dl><dt><span class="sect1"><a href="io_and_c.html#manual.io.c.FILE">Using FILE* and file descriptors</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch28s02.html">Performance</a></span></dt></dl></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt10ch23s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="iostream_objects.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">C99 </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 24. Iostream Objects</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/io_and_c.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/io_and_c.html
deleted file mode 100644
index 7e7798e9f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/io_and_c.html
+++ /dev/null
@@ -1,11 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 28. Interacting with C</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="io.html" title="Part XI.  Input and Output" /><link rel="prev" href="bk01pt11ch27s03.html" title="More Binary Input and Output" /><link rel="next" href="bk01pt11ch28s02.html" title="Performance" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 28. Interacting with C</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt11ch27s03.html">Prev</a> </td><th width="60%" align="center">Part XI. 
- Input and Output
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt11ch28s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.io.c"></a>Chapter 28. Interacting with C</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="io_and_c.html#manual.io.c.FILE">Using FILE* and file descriptors</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch28s02.html">Performance</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.io.c.FILE"></a>Using FILE* and file descriptors</h2></div></div></div><p>
- See the <a class="link" href="ext_io.html" title="Chapter 38. Input and Output">extensions</a> for using
- <span class="type">FILE</span> and <span class="type">file descriptors</span> with
- <code class="classname">ofstream</code> and
- <code class="classname">ifstream</code>.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt11ch27s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="io.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt11ch28s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">More Binary Input and Output </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Performance</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/iostream_objects.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/iostream_objects.html
deleted file mode 100644
index 5b6de7060..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/iostream_objects.html
+++ /dev/null
@@ -1,119 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 24. Iostream Objects</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="io.html" title="Part XI.  Input and Output" /><link rel="prev" href="io.html" title="Part XI.  Input and Output" /><link rel="next" href="streambufs.html" title="Chapter 25. Stream Buffers" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 24. Iostream Objects</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="io.html">Prev</a> </td><th width="60%" align="center">Part XI. 
- Input and Output
-
-</th><td width="20%" align="right"> <a accesskey="n" href="streambufs.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.io.objects"></a>Chapter 24. Iostream Objects</h2></div></div></div><p>To minimize the time you have to wait on the compiler, it's good to
- only include the headers you really need. Many people simply include
- &lt;iostream&gt; when they don't need to -- and that can <span class="emphasis"><em>penalize
- your runtime as well.</em></span> Here are some tips on which header to use
- for which situations, starting with the simplest.
- </p><p><span class="emphasis"><em>&lt;iosfwd&gt;</em></span> should be included whenever you simply
- need the <span class="emphasis"><em>name</em></span> of an I/O-related class, such as
- "ofstream" or "basic_streambuf". Like the name
- implies, these are forward declarations. (A word to all you fellow
- old school programmers: trying to forward declare classes like
- "class istream;" won't work. Look in the iosfwd header if
- you'd like to know why.) For example,
- </p><pre class="programlisting">
- #include &lt;iosfwd&gt;
-
- class MyClass
- {
- ....
- std::ifstream&amp; input_file;
- };
-
- extern std::ostream&amp; operator&lt;&lt; (std::ostream&amp;, MyClass&amp;);
- </pre><p><span class="emphasis"><em>&lt;ios&gt;</em></span> declares the base classes for the entire
- I/O stream hierarchy, std::ios_base and std::basic_ios&lt;charT&gt;, the
- counting types std::streamoff and std::streamsize, the file
- positioning type std::fpos, and the various manipulators like
- std::hex, std::fixed, std::noshowbase, and so forth.
- </p><p>The ios_base class is what holds the format flags, the state flags,
- and the functions which change them (setf(), width(), precision(),
- etc). You can also store extra data and register callback functions
- through ios_base, but that has been historically underused. Anything
- which doesn't depend on the type of characters stored is consolidated
- here.
- </p><p>The template class basic_ios is the highest template class in the
- hierarchy; it is the first one depending on the character type, and
- holds all general state associated with that type: the pointer to the
- polymorphic stream buffer, the facet information, etc.
- </p><p><span class="emphasis"><em>&lt;streambuf&gt;</em></span> declares the template class
- basic_streambuf, and two standard instantiations, streambuf and
- wstreambuf. If you need to work with the vastly useful and capable
- stream buffer classes, e.g., to create a new form of storage
- transport, this header is the one to include.
- </p><p><span class="emphasis"><em>&lt;istream&gt;</em></span>/<span class="emphasis"><em>&lt;ostream&gt;</em></span> are
- the headers to include when you are using the &gt;&gt;/&lt;&lt;
- interface, or any of the other abstract stream formatting functions.
- For example,
- </p><pre class="programlisting">
- #include &lt;istream&gt;
-
- std::ostream&amp; operator&lt;&lt; (std::ostream&amp; os, MyClass&amp; c)
- {
- return os &lt;&lt; c.data1() &lt;&lt; c.data2();
- }
- </pre><p>The std::istream and std::ostream classes are the abstract parents of
- the various concrete implementations. If you are only using the
- interfaces, then you only need to use the appropriate interface header.
- </p><p><span class="emphasis"><em>&lt;iomanip&gt;</em></span> provides "extractors and inserters
- that alter information maintained by class ios_base and its derived
- classes," such as std::setprecision and std::setw. If you need
- to write expressions like <code class="code">os &lt;&lt; setw(3);</code> or
- <code class="code">is &gt;&gt; setbase(8);</code>, you must include &lt;iomanip&gt;.
- </p><p><span class="emphasis"><em>&lt;sstream&gt;</em></span>/<span class="emphasis"><em>&lt;fstream&gt;</em></span>
- declare the six stringstream and fstream classes. As they are the
- standard concrete descendants of istream and ostream, you will already
- know about them.
- </p><p>Finally, <span class="emphasis"><em>&lt;iostream&gt;</em></span> provides the eight standard
- global objects (cin, cout, etc). To do this correctly, this header
- also provides the contents of the &lt;istream&gt; and &lt;ostream&gt;
- headers, but nothing else. The contents of this header look like
- </p><pre class="programlisting">
- #include &lt;ostream&gt;
- #include &lt;istream&gt;
-
- namespace std
- {
- extern istream cin;
- extern ostream cout;
- ....
-
- // this is explained below
- <span class="emphasis"><em>static ios_base::Init __foo;</em></span> // not its real name
- }
- </pre><p>Now, the runtime penalty mentioned previously: the global objects
- must be initialized before any of your own code uses them; this is
- guaranteed by the standard. Like any other global object, they must
- be initialized once and only once. This is typically done with a
- construct like the one above, and the nested class ios_base::Init is
- specified in the standard for just this reason.
- </p><p>How does it work? Because the header is included before any of your
- code, the <span class="emphasis"><em>__foo</em></span> object is constructed before any of
- your objects. (Global objects are built in the order in which they
- are declared, and destroyed in reverse order.) The first time the
- constructor runs, the eight stream objects are set up.
- </p><p>The <code class="code">static</code> keyword means that each object file compiled
- from a source file containing &lt;iostream&gt; will have its own
- private copy of <span class="emphasis"><em>__foo</em></span>. There is no specified order
- of construction across object files (it's one of those pesky NP
- problems that make life so interesting), so one copy in each object
- file means that the stream objects are guaranteed to be set up before
- any of your code which uses them could run, thereby meeting the
- requirements of the standard.
- </p><p>The penalty, of course, is that after the first copy of
- <span class="emphasis"><em>__foo</em></span> is constructed, all the others are just wasted
- processor time. The time spent is merely for an increment-and-test
- inside a function call, but over several dozen or hundreds of object
- files, that time can add up. (It's not in a tight loop, either.)
- </p><p>The lesson? Only include &lt;iostream&gt; when you need to use one of
- the standard objects in that source file; you'll pay less startup
- time. Only include the header files you need to in general; your
- compile times will go down when there's less parsing work to do.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="io.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="io.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="streambufs.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part XI. 
- Input and Output
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 25. Stream Buffers</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/iterators.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/iterators.html
deleted file mode 100644
index a76b38768..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/iterators.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part VIII.  Iterators</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="bitset.html" title="bitset" /><link rel="next" href="bk01pt08ch19.html" title="Chapter 19. Predefined" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part VIII. 
- Iterators
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bitset.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt08ch19.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.iterators"></a>Part VIII. 
- Iterators
- <a id="id481218" class="indexterm"></a>
-</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="bk01pt08ch19.html">19. Predefined</a></span></dt><dd><dl><dt><span class="sect1"><a href="bk01pt08ch19.html#iterators.predefined.vs_pointers">Iterators vs. Pointers</a></span></dt><dt><span class="sect1"><a href="bk01pt08ch19s02.html">One Past the End</a></span></dt></dl></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bitset.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt08ch19.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">bitset </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 19. Predefined</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/license.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/license.html
deleted file mode 100644
index 2e318f1ec..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/license.html
+++ /dev/null
@@ -1,105 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>License</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="status.html" title="Chapter 1. Status" /><link rel="prev" href="status.html" title="Chapter 1. Status" /><link rel="next" href="bugs.html" title="Bugs" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">License</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="status.html">Prev</a> </td><th width="60%" align="center">Chapter 1. Status</th><td width="20%" align="right"> <a accesskey="n" href="bugs.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.status.license"></a>License</h2></div></div></div><p>
- There are two licenses affecting GNU libstdc++: one for the code,
- and one for the documentation.
- </p><p>
- There is a license section in the FAQ regarding common <a class="link" href="../faq.html#faq.license" title="License">questions</a>. If you have more
- questions, ask the FSF or the <a class="ulink" href="http://gcc.gnu.org/lists.html" target="_top">gcc mailing list</a>.
- </p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.license.gpl"></a>The Code: GPL</h3></div></div></div><p>
- The source code is distributed under the <a class="link" href="appendix_gpl.html" title="Appendix D.  GNU General Public License version 3">GNU General Public License version 3</a>,
- with the addition under section 7 of an exception described in
- the “<span class="quote">GCC Runtime Library Exception, version 3.1</span>”
- as follows (or see the file COPYING.RUNTIME):
- </p><div class="literallayout"><p><br />
-GCC RUNTIME LIBRARY EXCEPTION<br />
-<br />
-Version 3.1, 31 March 2009<br />
-<br />
-Copyright (C) 2009 <a class="ulink" href="http://fsf.org" target="_top">Free Software Foundation, Inc.</a><br />
-<br />
-Everyone is permitted to copy and distribute verbatim copies of this<br />
-license document, but changing it is not allowed.<br />
-<br />
-This GCC Runtime Library Exception ("Exception") is an additional<br />
-permission under section 7 of the GNU General Public License, version<br />
-3 ("GPLv3"). It applies to a given file (the "Runtime Library") that<br />
-bears a notice placed by the copyright holder of the file stating that<br />
-the file is governed by GPLv3 along with this Exception.<br />
-<br />
-When you use GCC to compile a program, GCC may combine portions of<br />
-certain GCC header files and runtime libraries with the compiled<br />
-program. The purpose of this Exception is to allow compilation of<br />
-non-GPL (including proprietary) programs to use, in this way, the<br />
-header files and runtime libraries covered by this Exception.<br />
-<br />
-0. Definitions.<br />
-<br />
-A file is an "Independent Module" if it either requires the Runtime<br />
-Library for execution after a Compilation Process, or makes use of an<br />
-interface provided by the Runtime Library, but is not otherwise based<br />
-on the Runtime Library.<br />
-<br />
-"GCC" means a version of the GNU Compiler Collection, with or without<br />
-modifications, governed by version 3 (or a specified later version) of<br />
-the GNU General Public License (GPL) with the option of using any<br />
-subsequent versions published by the FSF.<br />
-<br />
-"GPL-compatible Software" is software whose conditions of propagation,<br />
-modification and use would permit combination with GCC in accord with<br />
-the license of GCC.<br />
-<br />
-"Target Code" refers to output from any compiler for a real or virtual<br />
-target processor architecture, in executable form or suitable for<br />
-input to an assembler, loader, linker and/or execution<br />
-phase. Notwithstanding that, Target Code does not include data in any<br />
-format that is used as a compiler intermediate representation, or used<br />
-for producing a compiler intermediate representation.<br />
-<br />
-The "Compilation Process" transforms code entirely represented in<br />
-non-intermediate languages designed for human-written code, and/or in<br />
-Java Virtual Machine byte code, into Target Code. Thus, for example,<br />
-use of source code generators and preprocessors need not be considered<br />
-part of the Compilation Process, since the Compilation Process can be<br />
-understood as starting with the output of the generators or<br />
-preprocessors.<br />
-<br />
-A Compilation Process is "Eligible" if it is done using GCC, alone or<br />
-with other GPL-compatible software, or if it is done without using any<br />
-work based on GCC. For example, using non-GPL-compatible Software to<br />
-optimize any GCC intermediate representations would not qualify as an<br />
-Eligible Compilation Process.<br />
-<br />
-1. Grant of Additional Permission.<br />
-<br />
-You have permission to propagate a work of Target Code formed by<br />
-combining the Runtime Library with Independent Modules, even if such<br />
-propagation would otherwise violate the terms of GPLv3, provided that<br />
-all Target Code was generated by Eligible Compilation Processes. You<br />
-may then convey such a combination under terms of your choice,<br />
-consistent with the licensing of the Independent Modules.<br />
-<br />
-2. No Weakening of GCC Copyleft.<br />
-<br />
-The availability of this Exception does not imply any general<br />
-presumption that third-party software is unaffected by the copyleft<br />
-requirements of the license of GCC.<br />
-    </p></div><p>
- Hopefully that text is self-explanatory. If it isn't, you need to speak
- to your lawyer, or the Free Software Foundation.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.license.fdl"></a>The Documentation: GPL, FDL</h3></div></div></div><p>
- The documentation shipped with the library and made available over
- the web, excluding the pages generated from source comments, are
- copyrighted by the Free Software Foundation, and placed under the
- <a class="link" href="appendix_gfdl.html" title="Appendix E. GNU Free Documentation License"> GNU Free Documentation
- License version 1.2</a>. There are no Front-Cover Texts, no
- Back-Cover Texts, and no Invariant Sections.
- </p><p>
- For documentation generated by doxygen or other automated tools
- via processing source code comments and markup, the original source
- code license applies to the generated files. Thus, the doxygen
- documents are licensed <a class="link" href="appendix_gpl.html" title="Appendix D.  GNU General Public License version 3">GPL</a>.
- </p><p>
- If you plan on making copies of the documentation, please let us know.
- We can probably offer suggestions.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="status.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="status.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bugs.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 1. Status </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Bugs</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/locales.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/locales.html
deleted file mode 100644
index d5f0b43bb..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/locales.html
+++ /dev/null
@@ -1,428 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 14. Locales</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="localization.html" title="Part VI.  Localization" /><link rel="prev" href="localization.html" title="Part VI.  Localization" /><link rel="next" href="facets.html" title="Chapter 15. Facets aka Categories" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 14. Locales</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="localization.html">Prev</a> </td><th width="60%" align="center">Part VI. 
- Localization
-
-</th><td width="20%" align="right"> <a accesskey="n" href="facets.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.localization.locales"></a>Chapter 14. Locales</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="locales.html#manual.localization.locales.locale">locale</a></span></dt><dd><dl><dt><span class="sect2"><a href="locales.html#locales.locale.req">Requirements</a></span></dt><dt><span class="sect2"><a href="locales.html#locales.locale.design">Design</a></span></dt><dt><span class="sect2"><a href="locales.html#locales.locale.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="locales.html#locales.locale.future">Future</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.localization.locales.locale"></a>locale</h2></div></div></div><p>
-Describes the basic locale object, including nested
-classes id, facet, and the reference-counted implementation object,
-class _Impl.
-</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="locales.locale.req"></a>Requirements</h3></div></div></div><p>
-Class locale is non-templatized and has two distinct types nested
-inside of it:
-</p><div class="blockquote"><blockquote class="blockquote"><p>
-<span class="emphasis"><em>
-class facet
-22.1.1.1.2 Class locale::facet
-</em></span>
-</p></blockquote></div><p>
-Facets actually implement locale functionality. For instance, a facet
-called numpunct is the data objects that can be used to query for the
-thousands separator is in the German locale.
-</p><p>
-Literally, a facet is strictly defined:
-</p><div class="itemizedlist"><ul type="disc"><li><p>
- Containing the following public data member:
- </p><p>
- <code class="code">static locale::id id;</code>
- </p></li><li><p>
- Derived from another facet:
- </p><p>
- <code class="code">class gnu_codecvt: public std::ctype&lt;user-defined-type&gt;</code>
- </p></li></ul></div><p>
-Of interest in this class are the memory management options explicitly
-specified as an argument to facet's constructor. Each constructor of a
-facet class takes a std::size_t __refs argument: if __refs == 0, the
-facet is deleted when the locale containing it is destroyed. If __refs
-== 1, the facet is not destroyed, even when it is no longer
-referenced.
-</p><div class="blockquote"><blockquote class="blockquote"><p>
-<span class="emphasis"><em>
-class id
-22.1.1.1.3 - Class locale::id
-</em></span>
-</p></blockquote></div><p>
-Provides an index for looking up specific facets.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="locales.locale.design"></a>Design</h3></div></div></div><p>
-The major design challenge is fitting an object-orientated and
-non-global locale design on top of POSIX and other relevant standards,
-which include the Single Unix (nee X/Open.)
-</p><p>
-Because C and earlier versions of POSIX fall down so completely,
-portability is an issue.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="locales.locale.impl"></a>Implementation</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="locale.impl.c"></a>Interacting with "C" locales</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
- <code class="code">`locale -a`</code> displays available locales.
- </p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">
-af_ZA
-ar_AE
-ar_AE.utf8
-ar_BH
-ar_BH.utf8
-ar_DZ
-ar_DZ.utf8
-ar_EG
-ar_EG.utf8
-ar_IN
-ar_IQ
-ar_IQ.utf8
-ar_JO
-ar_JO.utf8
-ar_KW
-ar_KW.utf8
-ar_LB
-ar_LB.utf8
-ar_LY
-ar_LY.utf8
-ar_MA
-ar_MA.utf8
-ar_OM
-ar_OM.utf8
-ar_QA
-ar_QA.utf8
-ar_SA
-ar_SA.utf8
-ar_SD
-ar_SD.utf8
-ar_SY
-ar_SY.utf8
-ar_TN
-ar_TN.utf8
-ar_YE
-ar_YE.utf8
-be_BY
-be_BY.utf8
-bg_BG
-bg_BG.utf8
-br_FR
-bs_BA
-C
-ca_ES
-ca_ES@euro
-ca_ES.utf8
-ca_ES.utf8@euro
-cs_CZ
-cs_CZ.utf8
-cy_GB
-da_DK
-da_DK.iso885915
-da_DK.utf8
-de_AT
-de_AT@euro
-de_AT.utf8
-de_AT.utf8@euro
-de_BE
-de_BE@euro
-de_BE.utf8
-de_BE.utf8@euro
-de_CH
-de_CH.utf8
-de_DE
-de_DE@euro
-de_DE.utf8
-de_DE.utf8@euro
-de_LU
-de_LU@euro
-de_LU.utf8
-de_LU.utf8@euro
-el_GR
-el_GR.utf8
-en_AU
-en_AU.utf8
-en_BW
-en_BW.utf8
-en_CA
-en_CA.utf8
-en_DK
-en_DK.utf8
-en_GB
-en_GB.iso885915
-en_GB.utf8
-en_HK
-en_HK.utf8
-en_IE
-en_IE@euro
-en_IE.utf8
-en_IE.utf8@euro
-en_IN
-en_NZ
-en_NZ.utf8
-en_PH
-en_PH.utf8
-en_SG
-en_SG.utf8
-en_US
-en_US.iso885915
-en_US.utf8
-en_ZA
-en_ZA.utf8
-en_ZW
-en_ZW.utf8
-es_AR
-es_AR.utf8
-es_BO
-es_BO.utf8
-es_CL
-es_CL.utf8
-es_CO
-es_CO.utf8
-es_CR
-es_CR.utf8
-es_DO
-es_DO.utf8
-es_EC
-es_EC.utf8
-es_ES
-es_ES@euro
-es_ES.utf8
-es_ES.utf8@euro
-es_GT
-es_GT.utf8
-es_HN
-es_HN.utf8
-es_MX
-es_MX.utf8
-es_NI
-es_NI.utf8
-es_PA
-es_PA.utf8
-es_PE
-es_PE.utf8
-es_PR
-es_PR.utf8
-es_PY
-es_PY.utf8
-es_SV
-es_SV.utf8
-es_US
-es_US.utf8
-es_UY
-es_UY.utf8
-es_VE
-es_VE.utf8
-et_EE
-et_EE.utf8
-eu_ES
-eu_ES@euro
-eu_ES.utf8
-eu_ES.utf8@euro
-fa_IR
-fi_FI
-fi_FI@euro
-fi_FI.utf8
-fi_FI.utf8@euro
-fo_FO
-fo_FO.utf8
-fr_BE
-fr_BE@euro
-fr_BE.utf8
-fr_BE.utf8@euro
-fr_CA
-fr_CA.utf8
-fr_CH
-fr_CH.utf8
-fr_FR
-fr_FR@euro
-fr_FR.utf8
-fr_FR.utf8@euro
-fr_LU
-fr_LU@euro
-fr_LU.utf8
-fr_LU.utf8@euro
-ga_IE
-ga_IE@euro
-ga_IE.utf8
-ga_IE.utf8@euro
-gl_ES
-gl_ES@euro
-gl_ES.utf8
-gl_ES.utf8@euro
-gv_GB
-gv_GB.utf8
-he_IL
-he_IL.utf8
-hi_IN
-hr_HR
-hr_HR.utf8
-hu_HU
-hu_HU.utf8
-id_ID
-id_ID.utf8
-is_IS
-is_IS.utf8
-it_CH
-it_CH.utf8
-it_IT
-it_IT@euro
-it_IT.utf8
-it_IT.utf8@euro
-iw_IL
-iw_IL.utf8
-ja_JP.eucjp
-ja_JP.utf8
-ka_GE
-kl_GL
-kl_GL.utf8
-ko_KR.euckr
-ko_KR.utf8
-kw_GB
-kw_GB.utf8
-lt_LT
-lt_LT.utf8
-lv_LV
-lv_LV.utf8
-mi_NZ
-mk_MK
-mk_MK.utf8
-mr_IN
-ms_MY
-ms_MY.utf8
-mt_MT
-mt_MT.utf8
-nl_BE
-nl_BE@euro
-nl_BE.utf8
-nl_BE.utf8@euro
-nl_NL
-nl_NL@euro
-nl_NL.utf8
-nl_NL.utf8@euro
-nn_NO
-nn_NO.utf8
-no_NO
-no_NO.utf8
-oc_FR
-pl_PL
-pl_PL.utf8
-POSIX
-pt_BR
-pt_BR.utf8
-pt_PT
-pt_PT@euro
-pt_PT.utf8
-pt_PT.utf8@euro
-ro_RO
-ro_RO.utf8
-ru_RU
-ru_RU.koi8r
-ru_RU.utf8
-ru_UA
-ru_UA.utf8
-se_NO
-sk_SK
-sk_SK.utf8
-sl_SI
-sl_SI.utf8
-sq_AL
-sq_AL.utf8
-sr_YU
-sr_YU@cyrillic
-sr_YU.utf8
-sr_YU.utf8@cyrillic
-sv_FI
-sv_FI@euro
-sv_FI.utf8
-sv_FI.utf8@euro
-sv_SE
-sv_SE.iso885915
-sv_SE.utf8
-ta_IN
-te_IN
-tg_TJ
-th_TH
-th_TH.utf8
-tl_PH
-tr_TR
-tr_TR.utf8
-uk_UA
-uk_UA.utf8
-ur_PK
-uz_UZ
-vi_VN
-vi_VN.tcvn
-wa_BE
-wa_BE@euro
-yi_US
-zh_CN
-zh_CN.gb18030
-zh_CN.gbk
-zh_CN.utf8
-zh_HK
-zh_HK.utf8
-zh_TW
-zh_TW.euctw
-zh_TW.utf8
-</pre></blockquote></div></li><li><p>
- <code class="code">`locale`</code> displays environmental variables that
- impact how locale("") will be deduced.
- </p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">
-LANG=en_US
-LC_CTYPE="en_US"
-LC_NUMERIC="en_US"
-LC_TIME="en_US"
-LC_COLLATE="en_US"
-LC_MONETARY="en_US"
-LC_MESSAGES="en_US"
-LC_PAPER="en_US"
-LC_NAME="en_US"
-LC_ADDRESS="en_US"
-LC_TELEPHONE="en_US"
-LC_MEASUREMENT="en_US"
-LC_IDENTIFICATION="en_US"
-LC_ALL=
-</pre></blockquote></div></li></ul></div><p>
-From Josuttis, p. 697-698, which says, that "there is only *one*
-relation (of the C++ locale mechanism) to the C locale mechanism: the
-global C locale is modified if a named C++ locale object is set as the
-global locale" (emphasis Paolo), that is:
-</p><pre class="programlisting">std::locale::global(std::locale(""));</pre><p>affects the C functions as if the following call was made:</p><pre class="programlisting">std::setlocale(LC_ALL, "");</pre><p>
- On the other hand, there is *no* vice versa, that is, calling
- setlocale has *no* whatsoever on the C++ locale mechanism, in
- particular on the working of locale(""), which constructs the locale
- object from the environment of the running program, that is, in
- practice, the set of LC_ALL, LANG, etc. variable of the shell.
-</p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="locales.locale.future"></a>Future</h3></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
- Locale initialization: at what point does _S_classic, _S_global
- get initialized? Can named locales assume this initialization
- has already taken place?
- </p></li><li><p>
- Document how named locales error check when filling data
- members. I.e., a fr_FR locale that doesn't have
- numpunct::truename(): does it use "true"? Or is it a blank
- string? What's the convention?
- </p></li><li><p>
- Explain how locale aliasing happens. When does "de_DE" use "de"
- information? What is the rule for locales composed of just an
- ISO language code (say, "de") and locales with both an ISO
- language code and ISO country code (say, "de_DE").
- </p></li><li><p>
- What should non-required facet instantiations do? If the
- generic implementation is provided, then how to end-users
- provide specializations?
- </p></li></ul></div></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="locales.locale.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id458449"></a><p><span class="title"><i>
- The GNU C Library
- </i>. </span><span class="author"><span class="firstname">Roland</span> <span class="surname">McGrath</span>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2007 FSF. </span><span class="pagenums">Chapters 6 Character Set Handling and 7 Locales and Internationalization. </span></p></div><div class="biblioentry"><a id="id435397"></a><p><span class="title"><i>
- Correspondence
- </i>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2002 . </span></p></div><div class="biblioentry"><a id="id435426"></a><p><span class="title"><i>
- ISO/IEC 14882:1998 Programming languages - C++
- </i>. </span><span class="copyright">Copyright © 1998 ISO. </span></p></div><div class="biblioentry"><a id="id458376"></a><p><span class="title"><i>
- ISO/IEC 9899:1999 Programming languages - C
- </i>. </span><span class="copyright">Copyright © 1999 ISO. </span></p></div><div class="biblioentry"><a id="id458395"></a><p><span class="title"><i>
- System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x)
- </i>. </span><span class="copyright">Copyright © 1999
- The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. </span><span class="biblioid">
- <a class="ulink" href="http://www.opennc.org/austin/docreg.html" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id462775"></a><p><span class="title"><i>
- The C++ Programming Language, Special Edition
- </i>. </span><span class="author"><span class="firstname">Bjarne</span> <span class="surname">Stroustrup</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley, Inc.. </span><span class="pagenums">Appendix D. </span><span class="publisher"><span class="publishername">
- Addison Wesley
- . </span></span></p></div><div class="biblioentry"><a id="id428064"></a><p><span class="title"><i>
- Standard C++ IOStreams and Locales
- </i>. </span><span class="subtitle">
- Advanced Programmer's Guide and Reference
- . </span><span class="author"><span class="firstname">Angelika</span> <span class="surname">Langer</span>. </span><span class="author"><span class="firstname">Klaus</span> <span class="surname">Kreft</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley Longman, Inc.. </span><span class="publisher"><span class="publishername">
- Addison Wesley Longman
- . </span></span></p></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="localization.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="localization.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="facets.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part VI. 
- Localization
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 15. Facets aka Categories</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/localization.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/localization.html
deleted file mode 100644
index 69471981e..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/localization.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part VI.  Localization</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="bk01pt05ch13s06.html" title="CString (MFC)" /><link rel="next" href="locales.html" title="Chapter 14. Locales" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part VI. 
- Localization
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt05ch13s06.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="locales.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.localization"></a>Part VI. 
- Localization
- <a id="id420596" class="indexterm"></a>
-</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="locales.html">14. Locales</a></span></dt><dd><dl><dt><span class="sect1"><a href="locales.html#manual.localization.locales.locale">locale</a></span></dt><dd><dl><dt><span class="sect2"><a href="locales.html#locales.locale.req">Requirements</a></span></dt><dt><span class="sect2"><a href="locales.html#locales.locale.design">Design</a></span></dt><dt><span class="sect2"><a href="locales.html#locales.locale.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="locales.html#locales.locale.future">Future</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="facets.html">15. Facets aka Categories</a></span></dt><dd><dl><dt><span class="sect1"><a href="facets.html#manual.localization.facet.ctype">ctype</a></span></dt><dd><dl><dt><span class="sect2"><a href="facets.html#facet.ctype.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="facets.html#facet.ctype.future">Future</a></span></dt></dl></dd><dt><span class="sect1"><a href="codecvt.html">codecvt</a></span></dt><dd><dl><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.req">Requirements</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.design">Design</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.use">Use</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.future">Future</a></span></dt></dl></dd><dt><span class="sect1"><a href="messages.html">messages</a></span></dt><dd><dl><dt><span class="sect2"><a href="messages.html#facet.messages.req">Requirements</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.design">Design</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.use">Use</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.future">Future</a></span></dt></dl></dd></dl></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt05ch13s06.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="locales.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">CString (MFC) </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 14. Locales</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/make.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/make.html
deleted file mode 100644
index 410992d28..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/make.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Make</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="setup.html" title="Chapter 2. Setup" /><link rel="prev" href="configure.html" title="Configure" /><link rel="next" href="test.html" title="Test" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Make</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="configure.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Setup</th><td width="20%" align="right"> <a accesskey="n" href="test.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.setup.make"></a>Make</h2></div></div></div><p>If you have never done this before, you should read the basic
- <a class="ulink" href="http://gcc.gnu.org/install/" target="_top">GCC Installation
- Instructions</a> first. Read <span class="emphasis"><em>all of them</em></span>.
- <span class="emphasis"><em>Twice.</em></span>
- </p><p>Then type:<span class="command"><strong>make</strong></span>, and congratulations, you're
-started to build.
-</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="configure.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="setup.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="test.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Configure </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Test</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/memory.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/memory.html
deleted file mode 100644
index 47327f3f1..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/memory.html
+++ /dev/null
@@ -1,349 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 11. Memory</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="utilities.html" title="Part IV.  Utilities" /><link rel="prev" href="pairs.html" title="Chapter 10. Pairs" /><link rel="next" href="auto_ptr.html" title="auto_ptr" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 11. Memory</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="pairs.html">Prev</a> </td><th width="60%" align="center">Part IV. 
- Utilities
-
-</th><td width="20%" align="right"> <a accesskey="n" href="auto_ptr.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.util.memory"></a>Chapter 11. Memory</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="memory.html#manual.util.memory.allocator">Allocators</a></span></dt><dd><dl><dt><span class="sect2"><a href="memory.html#allocator.req">Requirements</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.using">Using a Specific Allocator</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.custom">Custom Allocators</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.ext">Extension Allocators</a></span></dt></dl></dd><dt><span class="sect1"><a href="auto_ptr.html">auto_ptr</a></span></dt><dd><dl><dt><span class="sect2"><a href="auto_ptr.html#auto_ptr.limitations">Limitations</a></span></dt><dt><span class="sect2"><a href="auto_ptr.html#auto_ptr.using">Use in Containers</a></span></dt></dl></dd><dt><span class="sect1"><a href="shared_ptr.html">shared_ptr</a></span></dt><dd><dl><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.req">Requirements</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.using">Use</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.ack">Acknowledgments</a></span></dt></dl></dd></dl></div><p>
- Memory contains three general areas. First, function and operator
- calls via <code class="function">new</code> and <code class="function">delete</code>
- operator or member function calls. Second, allocation via
- <code class="classname">allocator</code>. And finally, smart pointer and
- intelligent pointer abstractions.
- </p><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.util.memory.allocator"></a>Allocators</h2></div></div></div><p>
- Memory management for Standard Library entities is encapsulated in a
- class template called <code class="classname">allocator</code>. The
- <code class="classname">allocator</code> abstraction is used throughout the
- library in <code class="classname">string</code>, container classes,
- algorithms, and parts of iostreams. This class, and base classes of
- it, are the superset of available free store (“<span class="quote">heap</span>”)
- management classes.
-</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.req"></a>Requirements</h3></div></div></div><p>
- The C++ standard only gives a few directives in this area:
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- When you add elements to a container, and the container must
- allocate more memory to hold them, the container makes the
- request via its <span class="type">Allocator</span> template
- parameter, which is usually aliased to
- <span class="type">allocator_type</span>. This includes adding chars
- to the string class, which acts as a regular STL container in
- this respect.
- </p></li><li><p>
- The default <span class="type">Allocator</span> argument of every
- container-of-T is <code class="classname">allocator&lt;T&gt;</code>.
- </p></li><li><p>
- The interface of the <code class="classname">allocator&lt;T&gt;</code> class is
- extremely simple. It has about 20 public declarations (nested
- typedefs, member functions, etc), but the two which concern us most
- are:
- </p><pre class="programlisting">
- T* allocate (size_type n, const void* hint = 0);
- void deallocate (T* p, size_type n);
- </pre><p>
- The <code class="varname">n</code> arguments in both those
- functions is a <span class="emphasis"><em>count</em></span> of the number of
- <span class="type">T</span>'s to allocate space for, <span class="emphasis"><em>not their
- total size</em></span>.
- (This is a simplification; the real signatures use nested typedefs.)
- </p></li><li><p>
- The storage is obtained by calling <code class="function">::operator
- new</code>, but it is unspecified when or how
- often this function is called. The use of the
- <code class="varname">hint</code> is unspecified, but intended as an
- aid to locality if an implementation so
- desires. <code class="constant">[20.4.1.1]/6</code>
- </p></li></ul></div><p>
- Complete details cam be found in the C++ standard, look in
- <code class="constant">[20.4 Memory]</code>.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.design_issues"></a>Design Issues</h3></div></div></div><p>
- The easiest way of fulfilling the requirements is to call
- <code class="function">operator new</code> each time a container needs
- memory, and to call <code class="function">operator delete</code> each time
- the container releases memory. This method may be <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00105.html" target="_top">slower</a>
- than caching the allocations and re-using previously-allocated
- memory, but has the advantage of working correctly across a wide
- variety of hardware and operating systems, including large
- clusters. The <code class="classname">__gnu_cxx::new_allocator</code>
- implements the simple operator new and operator delete semantics,
- while <code class="classname">__gnu_cxx::malloc_allocator</code>
- implements much the same thing, only with the C language functions
- <code class="function">std::malloc</code> and <code class="function">free</code>.
- </p><p>
- Another approach is to use intelligence within the allocator
- class to cache allocations. This extra machinery can take a variety
- of forms: a bitmap index, an index into an exponentially increasing
- power-of-two-sized buckets, or simpler fixed-size pooling cache.
- The cache is shared among all the containers in the program: when
- your program's <code class="classname">std::vector&lt;int&gt;</code> gets
- cut in half and frees a bunch of its storage, that memory can be
- reused by the private
- <code class="classname">std::list&lt;WonkyWidget&gt;</code> brought in from
- a KDE library that you linked against. And operators
- <code class="function">new</code> and <code class="function">delete</code> are not
- always called to pass the memory on, either, which is a speed
- bonus. Examples of allocators that use these techniques are
- <code class="classname">__gnu_cxx::bitmap_allocator</code>,
- <code class="classname">__gnu_cxx::pool_allocator</code>, and
- <code class="classname">__gnu_cxx::__mt_alloc</code>.
- </p><p>
- Depending on the implementation techniques used, the underlying
- operating system, and compilation environment, scaling caching
- allocators can be tricky. In particular, order-of-destruction and
- order-of-creation for memory pools may be difficult to pin down
- with certainty, which may create problems when used with plugins
- or loading and unloading shared objects in memory. As such, using
- caching allocators on systems that do not support
- <code class="function">abi::__cxa_atexit</code> is not recommended.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.impl"></a>Implementation</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id419128"></a>Interface Design</h4></div></div></div><p>
- The only allocator interface that
- is support is the standard C++ interface. As such, all STL
- containers have been adjusted, and all external allocators have
- been modified to support this change.
- </p><p>
- The class <code class="classname">allocator</code> just has typedef,
- constructor, and rebind members. It inherits from one of the
- high-speed extension allocators, covered below. Thus, all
- allocation and deallocation depends on the base class.
- </p><p>
- The base class that <code class="classname">allocator</code> is derived from
- may not be user-configurable.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id410525"></a>Selecting Default Allocation Policy</h4></div></div></div><p>
- It's difficult to pick an allocation strategy that will provide
- maximum utility, without excessively penalizing some behavior. In
- fact, it's difficult just deciding which typical actions to measure
- for speed.
- </p><p>
- Three synthetic benchmarks have been created that provide data
- that is used to compare different C++ allocators. These tests are:
- </p><div class="orderedlist"><ol type="1"><li><p>
- Insertion.
- </p><p>
- Over multiple iterations, various STL container
- objects have elements inserted to some maximum amount. A variety
- of allocators are tested.
- Test source for <a class="ulink" href="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/insert/sequence.cc?view=markup" target="_top">sequence</a>
- and <a class="ulink" href="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/insert/associative.cc?view=markup" target="_top">associative</a>
- containers.
- </p></li><li><p>
- Insertion and erasure in a multi-threaded environment.
- </p><p>
- This test shows the ability of the allocator to reclaim memory
- on a pre-thread basis, as well as measuring thread contention
- for memory resources.
- Test source
- <a class="ulink" href="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/insert_erase/associative.cc?view=markup" target="_top">here</a>.
- </p></li><li><p>
- A threaded producer/consumer model.
- </p><p>
- Test source for
- <a class="ulink" href="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/producer_consumer/sequence.cc?view=markup" target="_top">sequence</a>
- and
- <a class="ulink" href="http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/performance/23_containers/producer_consumer/associative.cc?view=markup" target="_top">associative</a>
- containers.
- </p></li></ol></div><p>
- The current default choice for
- <code class="classname">allocator</code> is
- <code class="classname">__gnu_cxx::new_allocator</code>.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id457524"></a>Disabling Memory Caching</h4></div></div></div><p>
- In use, <code class="classname">allocator</code> may allocate and
- deallocate using implementation-specified strategies and
- heuristics. Because of this, every call to an allocator object's
- <code class="function">allocate</code> member function may not actually
- call the global operator new. This situation is also duplicated
- for calls to the <code class="function">deallocate</code> member
- function.
- </p><p>
- This can be confusing.
- </p><p>
- In particular, this can make debugging memory errors more
- difficult, especially when using third party tools like valgrind or
- debug versions of <code class="function">new</code>.
- </p><p>
- There are various ways to solve this problem. One would be to use
- a custom allocator that just called operators
- <code class="function">new</code> and <code class="function">delete</code>
- directly, for every allocation. (See
- <code class="filename">include/ext/new_allocator.h</code>, for instance.)
- However, that option would involve changing source code to use
- a non-default allocator. Another option is to force the
- default allocator to remove caching and pools, and to directly
- allocate with every call of <code class="function">allocate</code> and
- directly deallocate with every call of
- <code class="function">deallocate</code>, regardless of efficiency. As it
- turns out, this last option is also available.
- </p><p>
- To globally disable memory caching within the library for the
- default allocator, merely set
- <code class="constant">GLIBCXX_FORCE_NEW</code> (with any value) in the
- system's environment before running the program. If your program
- crashes with <code class="constant">GLIBCXX_FORCE_NEW</code> in the
- environment, it likely means that you linked against objects
- built against the older library (objects which might still using the
- cached allocations...).
- </p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.using"></a>Using a Specific Allocator</h3></div></div></div><p>
- You can specify different memory management schemes on a
- per-container basis, by overriding the default
- <span class="type">Allocator</span> template parameter. For example, an easy
- (but non-portable) method of specifying that only <code class="function">malloc</code> or <code class="function">free</code>
- should be used instead of the default node allocator is:
- </p><pre class="programlisting">
- std::list &lt;int, __gnu_cxx::malloc_allocator&lt;int&gt; &gt; malloc_list;</pre><p>
- Likewise, a debugging form of whichever allocator is currently in use:
- </p><pre class="programlisting">
- std::deque &lt;int, __gnu_cxx::debug_allocator&lt;std::allocator&lt;int&gt; &gt; &gt; debug_deque;
- </pre></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.custom"></a>Custom Allocators</h3></div></div></div><p>
- Writing a portable C++ allocator would dictate that the interface
- would look much like the one specified for
- <code class="classname">allocator</code>. Additional member functions, but
- not subtractions, would be permissible.
- </p><p>
- Probably the best place to start would be to copy one of the
- extension allocators: say a simple one like
- <code class="classname">new_allocator</code>.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.ext"></a>Extension Allocators</h3></div></div></div><p>
- Several other allocators are provided as part of this
- implementation. The location of the extension allocators and their
- names have changed, but in all cases, functionality is
- equivalent. Starting with gcc-3.4, all extension allocators are
- standard style. Before this point, SGI style was the norm. Because of
- this, the number of template arguments also changed. Here's a simple
- chart to track the changes.
- </p><p>
- More details on each of these extension allocators follows.
- </p><div class="orderedlist"><ol type="1"><li><p>
- <code class="classname">new_allocator</code>
- </p><p>
- Simply wraps <code class="function">::operator new</code>
- and <code class="function">::operator delete</code>.
- </p></li><li><p>
- <code class="classname">malloc_allocator</code>
- </p><p>
- Simply wraps <code class="function">malloc</code> and
- <code class="function">free</code>. There is also a hook for an
- out-of-memory handler (for
- <code class="function">new</code>/<code class="function">delete</code> this is
- taken care of elsewhere).
- </p></li><li><p>
- <code class="classname">array_allocator</code>
- </p><p>
- Allows allocations of known and fixed sizes using existing
- global or external storage allocated via construction of
- <code class="classname">std::tr1::array</code> objects. By using this
- allocator, fixed size containers (including
- <code class="classname">std::string</code>) can be used without
- instances calling <code class="function">::operator new</code> and
- <code class="function">::operator delete</code>. This capability
- allows the use of STL abstractions without runtime
- complications or overhead, even in situations such as program
- startup. For usage examples, please consult the testsuite.
- </p></li><li><p>
- <code class="classname">debug_allocator</code>
- </p><p>
- A wrapper around an arbitrary allocator A. It passes on
- slightly increased size requests to A, and uses the extra
- memory to store size information. When a pointer is passed
- to <code class="function">deallocate()</code>, the stored size is
- checked, and <code class="function">assert()</code> is used to
- guarantee they match.
- </p></li><li><p>
- <code class="classname">throw_allocator</code>
- </p><p>
- Includes memory tracking and marking abilities as well as hooks for
- throwing exceptions at configurable intervals (including random,
- all, none).
- </p></li><li><p>
- <code class="classname">__pool_alloc</code>
- </p><p>
- A high-performance, single pool allocator. The reusable
- memory is shared among identical instantiations of this type.
- It calls through <code class="function">::operator new</code> to
- obtain new memory when its lists run out. If a client
- container requests a block larger than a certain threshold
- size, then the pool is bypassed, and the allocate/deallocate
- request is passed to <code class="function">::operator new</code>
- directly.
- </p><p>
- Older versions of this class take a boolean template
- parameter, called <code class="varname">thr</code>, and an integer template
- parameter, called <code class="varname">inst</code>.
- </p><p>
- The <code class="varname">inst</code> number is used to track additional memory
- pools. The point of the number is to allow multiple
- instantiations of the classes without changing the semantics at
- all. All three of
- </p><pre class="programlisting">
- typedef __pool_alloc&lt;true,0&gt; normal;
- typedef __pool_alloc&lt;true,1&gt; private;
- typedef __pool_alloc&lt;true,42&gt; also_private;
- </pre><p>
- behave exactly the same way. However, the memory pool for each type
- (and remember that different instantiations result in different types)
- remains separate.
- </p><p>
- The library uses <span class="emphasis"><em>0</em></span> in all its instantiations. If you
- wish to keep separate free lists for a particular purpose, use a
- different number.
- </p><p>The <code class="varname">thr</code> boolean determines whether the
- pool should be manipulated atomically or not. When
- <code class="varname">thr</code> = <code class="constant">true</code>, the allocator
- is is thread-safe, while <code class="varname">thr</code> =
- <code class="constant">false</code>, and is slightly faster but unsafe for
- multiple threads.
- </p><p>
- For thread-enabled configurations, the pool is locked with a
- single big lock. In some situations, this implementation detail
- may result in severe performance degradation.
- </p><p>
- (Note that the GCC thread abstraction layer allows us to provide
- safe zero-overhead stubs for the threading routines, if threads
- were disabled at configuration time.)
- </p></li><li><p>
- <code class="classname">__mt_alloc</code>
- </p><p>
- A high-performance fixed-size allocator with
- exponentially-increasing allocations. It has its own
- documentation, found <a class="link" href="ext_allocators.html#manual.ext.allocator.mt" title="mt_allocator">here</a>.
- </p></li><li><p>
- <code class="classname">bitmap_allocator</code>
- </p><p>
- A high-performance allocator that uses a bit-map to keep track
- of the used and unused memory locations. It has its own
- documentation, found <a class="link" href="bitmap_allocator.html" title="bitmap_allocator">here</a>.
- </p></li></ol></div></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="allocator.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id455580"></a><p><span class="title"><i>
- ISO/IEC 14882:1998 Programming languages - C++
- </i>. </span>
- isoc++_1998
- <span class="pagenums">20.4 Memory. </span></p></div><div class="biblioentry"><a id="id408540"></a><p><span class="title"><i>The Standard Librarian: What Are Allocators Good
- </i>. </span>
- austernm
- <span class="author"><span class="firstname">Matt</span> <span class="surname">Austern</span>. </span><span class="publisher"><span class="publishername">
- C/C++ Users Journal
- . </span></span><span class="biblioid">
- <a class="ulink" href="http://www.cuj.com/documents/s=8000/cujcexp1812austern/" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id411757"></a><p><span class="title"><i>The Hoard Memory Allocator</i>. </span>
- emeryb
- <span class="author"><span class="firstname">Emery</span> <span class="surname">Berger</span>. </span><span class="biblioid">
- <a class="ulink" href="http://www.cs.umass.edu/~emery/hoard/" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id392744"></a><p><span class="title"><i>Reconsidering Custom Memory Allocation</i>. </span>
- bergerzorn
- <span class="author"><span class="firstname">Emery</span> <span class="surname">Berger</span>. </span><span class="author"><span class="firstname">Ben</span> <span class="surname">Zorn</span>. </span><span class="author"><span class="firstname">Kathryn</span> <span class="surname">McKinley</span>. </span><span class="copyright">Copyright © 2002 OOPSLA. </span><span class="biblioid">
- <a class="ulink" href="http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id422908"></a><p><span class="title"><i>Allocator Types</i>. </span>
- kreftlanger
- <span class="author"><span class="firstname">Klaus</span> <span class="surname">Kreft</span>. </span><span class="author"><span class="firstname">Angelika</span> <span class="surname">Langer</span>. </span><span class="publisher"><span class="publishername">
- C/C++ Users Journal
- . </span></span><span class="biblioid">
- <a class="ulink" href="http://www.langer.camelot.de/Articles/C++Report/Allocators/Allocators.html" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id395999"></a><p><span class="title"><i>The C++ Programming Language</i>. </span>
- tcpl
- <span class="author"><span class="firstname">Bjarne</span> <span class="surname">Stroustrup</span>. </span><span class="copyright">Copyright © 2000 . </span><span class="pagenums">19.4 Allocators. </span><span class="publisher"><span class="publishername">
- Addison Wesley
- . </span></span></p></div><div class="biblioentry"><a id="id398620"></a><p><span class="title"><i>Yalloc: A Recycling C++ Allocator</i>. </span>
- yenf
- <span class="author"><span class="firstname">Felix</span> <span class="surname">Yen</span>. </span><span class="copyright">Copyright © . </span><span class="biblioid">
- <a class="ulink" href="http://home.earthlink.net/~brimar/yalloc/" target="_top">
- </a>
- . </span></p></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="pairs.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="utilities.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="auto_ptr.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 10. Pairs </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> auto_ptr</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/messages.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/messages.html
deleted file mode 100644
index 67327cc27..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/messages.html
+++ /dev/null
@@ -1,284 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>messages</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; messages&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="facets.html" title="Chapter 15. Facets aka Categories" /><link rel="prev" href="codecvt.html" title="codecvt" /><link rel="next" href="containers.html" title="Part VII.  Containers" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">messages</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="codecvt.html">Prev</a> </td><th width="60%" align="center">Chapter 15. Facets aka Categories</th><td width="20%" align="right"> <a accesskey="n" href="containers.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.localization.facet.messages"></a>messages</h2></div></div></div><p>
-The std::messages facet implements message retrieval functionality
-equivalent to Java's java.text.MessageFormat .using either GNU gettext
-or IEEE 1003.1-200 functions.
-</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.messages.req"></a>Requirements</h3></div></div></div><p>
-The std::messages facet is probably the most vaguely defined facet in
-the standard library. It's assumed that this facility was built into
-the standard library in order to convert string literals from one
-locale to the other. For instance, converting the "C" locale's
-<code class="code">const char* c = "please"</code> to a German-localized <code class="code">"bitte"</code>
-during program execution.
-</p><div class="blockquote"><blockquote class="blockquote"><p>
-22.2.7.1 - Template class messages [lib.locale.messages]
-</p></blockquote></div><p>
-This class has three public member functions, which directly
-correspond to three protected virtual member functions.
-</p><p>
-The public member functions are:
-</p><p>
-<code class="code">catalog open(const string&amp;, const locale&amp;) const</code>
-</p><p>
-<code class="code">string_type get(catalog, int, int, const string_type&amp;) const</code>
-</p><p>
-<code class="code">void close(catalog) const</code>
-</p><p>
-While the virtual functions are:
-</p><p>
-<code class="code">catalog do_open(const string&amp;, const locale&amp;) const</code>
-</p><div class="blockquote"><blockquote class="blockquote"><p>
-<span class="emphasis"><em>
--1- Returns: A value that may be passed to get() to retrieve a
-message, from the message catalog identified by the string name
-according to an implementation-defined mapping. The result can be used
-until it is passed to close(). Returns a value less than 0 if no such
-catalog can be opened.
-</em></span>
-</p></blockquote></div><p>
-<code class="code">string_type do_get(catalog, int, int, const string_type&amp;) const</code>
-</p><div class="blockquote"><blockquote class="blockquote"><p>
-<span class="emphasis"><em>
--3- Requires: A catalog cat obtained from open() and not yet closed.
--4- Returns: A message identified by arguments set, msgid, and dfault,
-according to an implementation-defined mapping. If no such message can
-be found, returns dfault.
-</em></span>
-</p></blockquote></div><p>
-<code class="code">void do_close(catalog) const</code>
-</p><div class="blockquote"><blockquote class="blockquote"><p>
-<span class="emphasis"><em>
--5- Requires: A catalog cat obtained from open() and not yet closed.
--6- Effects: Releases unspecified resources associated with cat.
--7- Notes: The limit on such resources, if any, is implementation-defined.
-</em></span>
-</p></blockquote></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.messages.design"></a>Design</h3></div></div></div><p>
-A couple of notes on the standard.
-</p><p>
-First, why is <code class="code">messages_base::catalog</code> specified as a typedef
-to int? This makes sense for implementations that use
-<code class="code">catopen</code>, but not for others. Fortunately, it's not heavily
-used and so only a minor irritant.
-</p><p>
-Second, by making the member functions <code class="code">const</code>, it is
-impossible to save state in them. Thus, storing away information used
-in the 'open' member function for use in 'get' is impossible. This is
-unfortunate.
-</p><p>
-The 'open' member function in particular seems to be oddly
-designed. The signature seems quite peculiar. Why specify a <code class="code">const
-string&amp; </code> argument, for instance, instead of just <code class="code">const
-char*</code>? Or, why specify a <code class="code">const locale&amp;</code> argument that is
-to be used in the 'get' member function? How, exactly, is this locale
-argument useful? What was the intent? It might make sense if a locale
-argument was associated with a given default message string in the
-'open' member function, for instance. Quite murky and unclear, on
-reflection.
-</p><p>
-Lastly, it seems odd that messages, which explicitly require code
-conversion, don't use the codecvt facet. Because the messages facet
-has only one template parameter, it is assumed that ctype, and not
-codecvt, is to be used to convert between character sets.
-</p><p>
-It is implicitly assumed that the locale for the default message
-string in 'get' is in the "C" locale. Thus, all source code is assumed
-to be written in English, so translations are always from "en_US" to
-other, explicitly named locales.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.messages.impl"></a>Implementation</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="messages.impl.models"></a>Models</h4></div></div></div><p>
- This is a relatively simple class, on the face of it. The standard
- specifies very little in concrete terms, so generic
- implementations that are conforming yet do very little are the
- norm. Adding functionality that would be useful to programmers and
- comparable to Java's java.text.MessageFormat takes a bit of work,
- and is highly dependent on the capabilities of the underlying
- operating system.
- </p><p>
- Three different mechanisms have been provided, selectable via
- configure flags:
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- generic
- </p><p>
- This model does very little, and is what is used by default.
- </p></li><li><p>
- gnu
- </p><p>
- The gnu model is complete and fully tested. It's based on the
- GNU gettext package, which is part of glibc. It uses the
- functions <code class="code">textdomain, bindtextdomain, gettext</code> to
- implement full functionality. Creating message catalogs is a
- relatively straight-forward process and is lightly documented
- below, and fully documented in gettext's distributed
- documentation.
- </p></li><li><p>
- ieee_1003.1-200x
- </p><p>
- This is a complete, though untested, implementation based on
- the IEEE standard. The functions <code class="code">catopen, catgets,
- catclose</code> are used to retrieve locale-specific messages
- given the appropriate message catalogs that have been
- constructed for their use. Note, the script <code class="code">
- po2msg.sed</code> that is part of the gettext distribution can
- convert gettext catalogs into catalogs that
- <code class="code">catopen</code> can use.
- </p></li></ul></div><p>
-A new, standards-conformant non-virtual member function signature was
-added for 'open' so that a directory could be specified with a given
-message catalog. This simplifies calling conventions for the gnu
-model.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="messages.impl.gnu"></a>The GNU Model</h4></div></div></div><p>
- The messages facet, because it is retrieving and converting
- between characters sets, depends on the ctype and perhaps the
- codecvt facet in a given locale. In addition, underlying "C"
- library locale support is necessary for more than just the
- <code class="code">LC_MESSAGES</code> mask: <code class="code">LC_CTYPE</code> is also
- necessary. To avoid any unpleasantness, all bits of the "C" mask
- (i.e. <code class="code">LC_ALL</code>) are set before retrieving messages.
- </p><p>
- Making the message catalogs can be initially tricky, but become
- quite simple with practice. For complete info, see the gettext
- documentation. Here's an idea of what is required:
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- Make a source file with the required string literals that need
- to be translated. See <code class="code">intl/string_literals.cc</code> for
- an example.
- </p></li><li><p>
- Make initial catalog (see "4 Making the PO Template File" from
- the gettext docs).</p><p>
- <code class="code"> xgettext --c++ --debug string_literals.cc -o libstdc++.pot </code>
- </p></li><li><p>Make language and country-specific locale catalogs.</p><p>
- <code class="code">cp libstdc++.pot fr_FR.po</code>
- </p><p>
- <code class="code">cp libstdc++.pot de_DE.po</code>
- </p></li><li><p>
- Edit localized catalogs in emacs so that strings are
- translated.
- </p><p>
- <code class="code">emacs fr_FR.po</code>
- </p></li><li><p>Make the binary mo files.</p><p>
- <code class="code">msgfmt fr_FR.po -o fr_FR.mo</code>
- </p><p>
- <code class="code">msgfmt de_DE.po -o de_DE.mo</code>
- </p></li><li><p>Copy the binary files into the correct directory structure.</p><p>
- <code class="code">cp fr_FR.mo (dir)/fr_FR/LC_MESSAGES/libstdc++.mo</code>
- </p><p>
- <code class="code">cp de_DE.mo (dir)/de_DE/LC_MESSAGES/libstdc++.mo</code>
- </p></li><li><p>Use the new message catalogs.</p><p>
- <code class="code">locale loc_de("de_DE");</code>
- </p><p>
- <code class="code">
- use_facet&lt;messages&lt;char&gt; &gt;(loc_de).open("libstdc++", locale(), dir);
- </code>
- </p></li></ul></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.messages.use"></a>Use</h3></div></div></div><p>
- A simple example using the GNU model of message conversion.
- </p><pre class="programlisting">
-#include &lt;iostream&gt;
-#include &lt;locale&gt;
-using namespace std;
-
-void test01()
-{
- typedef messages&lt;char&gt;::catalog catalog;
- const char* dir =
- "/mnt/egcs/build/i686-pc-linux-gnu/libstdc++/po/share/locale";
- const locale loc_de("de_DE");
- const messages&lt;char&gt;&amp; mssg_de = use_facet&lt;messages&lt;char&gt; &gt;(loc_de);
-
- catalog cat_de = mssg_de.open("libstdc++", loc_de, dir);
- string s01 = mssg_de.get(cat_de, 0, 0, "please");
- string s02 = mssg_de.get(cat_de, 0, 0, "thank you");
- cout &lt;&lt; "please in german:" &lt;&lt; s01 &lt;&lt; '\n';
- cout &lt;&lt; "thank you in german:" &lt;&lt; s02 &lt;&lt; '\n';
- mssg_de.close(cat_de);
-}
-</pre></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="facet.messages.future"></a>Future</h3></div></div></div><div class="itemizedlist"><ul type="disc"><li><p>
- Things that are sketchy, or remain unimplemented:
- </p><div class="itemizedlist"><ul type="circle"><li><p>
- _M_convert_from_char, _M_convert_to_char are in flux,
- depending on how the library ends up doing character set
- conversions. It might not be possible to do a real character
- set based conversion, due to the fact that the template
- parameter for messages is not enough to instantiate the
- codecvt facet (1 supplied, need at least 2 but would prefer
- 3).
- </p></li><li><p>
- There are issues with gettext needing the global locale set
- to extract a message. This dependence on the global locale
- makes the current "gnu" model non MT-safe. Future versions
- of glibc, i.e. glibc 2.3.x will fix this, and the C++ library
- bits are already in place.
- </p></li></ul></div></li><li><p>
- Development versions of the GNU "C" library, glibc 2.3 will allow
- a more efficient, MT implementation of std::messages, and will
- allow the removal of the _M_name_messages data member. If this is
- done, it will change the library ABI. The C++ parts to support
- glibc 2.3 have already been coded, but are not in use: once this
- version of the "C" library is released, the marked parts of the
- messages implementation can be switched over to the new "C"
- library functionality.
- </p></li><li><p>
- At some point in the near future, std::numpunct will probably use
- std::messages facilities to implement truename/falsename
- correctly. This is currently not done, but entries in
- libstdc++.pot have already been made for "true" and "false" string
- literals, so all that remains is the std::numpunct coding and the
- configure/make hassles to make the installed library search its
- own catalog. Currently the libstdc++.mo catalog is only searched
- for the testsuite cases involving messages members.
- </p></li><li><p> The following member functions:</p><p>
- <code class="code">
- catalog
- open(const basic_string&lt;char&gt;&amp; __s, const locale&amp; __loc) const
- </code>
- </p><p>
- <code class="code">
- catalog
- open(const basic_string&lt;char&gt;&amp;, const locale&amp;, const char*) const;
- </code>
- </p><p>
- Don't actually return a "value less than 0 if no such catalog
- can be opened" as required by the standard in the "gnu"
- model. As of this writing, it is unknown how to query to see
- if a specified message catalog exists using the gettext
- package.
- </p></li></ul></div></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="facet.messages.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id427517"></a><p><span class="title"><i>
- The GNU C Library
- </i>. </span><span class="author"><span class="firstname">Roland</span> <span class="surname">McGrath</span>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2007 FSF. </span><span class="pagenums">Chapters 6 Character Set Handling, and 7 Locales and Internationalization
- . </span></p></div><div class="biblioentry"><a id="id391329"></a><p><span class="title"><i>
- Correspondence
- </i>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span><span class="copyright">Copyright © 2002 . </span></p></div><div class="biblioentry"><a id="id391358"></a><p><span class="title"><i>
- ISO/IEC 14882:1998 Programming languages - C++
- </i>. </span><span class="copyright">Copyright © 1998 ISO. </span></p></div><div class="biblioentry"><a id="id514997"></a><p><span class="title"><i>
- ISO/IEC 9899:1999 Programming languages - C
- </i>. </span><span class="copyright">Copyright © 1999 ISO. </span></p></div><div class="biblioentry"><a id="id515015"></a><p><span class="title"><i>
- System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x)
- </i>. </span><span class="copyright">Copyright © 1999
- The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. </span><span class="biblioid">
- <a class="ulink" href="http://www.opennc.org/austin/docreg.html" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id427733"></a><p><span class="title"><i>
- The C++ Programming Language, Special Edition
- </i>. </span><span class="author"><span class="firstname">Bjarne</span> <span class="surname">Stroustrup</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley, Inc.. </span><span class="pagenums">Appendix D. </span><span class="publisher"><span class="publishername">
- Addison Wesley
- . </span></span></p></div><div class="biblioentry"><a id="id427774"></a><p><span class="title"><i>
- Standard C++ IOStreams and Locales
- </i>. </span><span class="subtitle">
- Advanced Programmer's Guide and Reference
- . </span><span class="author"><span class="firstname">Angelika</span> <span class="surname">Langer</span>. </span><span class="author"><span class="firstname">Klaus</span> <span class="surname">Kreft</span>. </span><span class="copyright">Copyright © 2000 Addison Wesley Longman, Inc.. </span><span class="publisher"><span class="publishername">
- Addison Wesley Longman
- . </span></span></p></div><div class="biblioentry"><a id="id402618"></a><p><span class="title"><i>
- Java 2 Platform, Standard Edition, v 1.3.1 API Specification
- </i>. </span><span class="pagenums">java.util.Properties, java.text.MessageFormat,
-java.util.Locale, java.util.ResourceBundle. </span><span class="biblioid">
- <a class="ulink" href="http://java.sun.com/j2se/1.3/docs/api" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id404627"></a><p><span class="title"><i>
- GNU gettext tools, version 0.10.38, Native Language Support
-Library and Tools.
- </i>. </span><span class="biblioid">
- <a class="ulink" href="http://sources.redhat.com/gettext" target="_top">
- </a>
- . </span></p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="codecvt.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="facets.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="containers.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">codecvt </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part VII. 
- Containers
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/numerics.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/numerics.html
deleted file mode 100644
index 321de258c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/numerics.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part X.  Numerics</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="bk01pt09ch20.html" title="Chapter 20. Mutating" /><link rel="next" href="complex.html" title="Chapter 21. Complex" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part X. 
- Numerics
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt09ch20.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="complex.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.numerics"></a>Part X. 
- Numerics
- <a id="id490280" class="indexterm"></a>
-</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="complex.html">21. Complex</a></span></dt><dd><dl><dt><span class="sect1"><a href="complex.html#numerics.complex.processing">complex Processing</a></span></dt></dl></dd><dt><span class="chapter"><a href="generalized_numeric_operations.html">22. Generalized Operations</a></span></dt><dt><span class="chapter"><a href="numerics_and_c.html">23. Interacting with C</a></span></dt><dd><dl><dt><span class="sect1"><a href="numerics_and_c.html#numerics.c.array">Numerics vs. Arrays</a></span></dt><dt><span class="sect1"><a href="bk01pt10ch23s02.html">C99</a></span></dt></dl></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt09ch20.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="complex.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 20. Mutating </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 21. Complex</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/numerics_and_c.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/numerics_and_c.html
deleted file mode 100644
index 3788ad313..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/numerics_and_c.html
+++ /dev/null
@@ -1,21 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 23. Interacting with C</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="numerics.html" title="Part X.  Numerics" /><link rel="prev" href="generalized_numeric_operations.html" title="Chapter 22. Generalized Operations" /><link rel="next" href="bk01pt10ch23s02.html" title="C99" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 23. Interacting with C</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="generalized_numeric_operations.html">Prev</a> </td><th width="60%" align="center">Part X. 
- Numerics
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt10ch23s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.numerics.c"></a>Chapter 23. Interacting with C</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="numerics_and_c.html#numerics.c.array">Numerics vs. Arrays</a></span></dt><dt><span class="sect1"><a href="bk01pt10ch23s02.html">C99</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="numerics.c.array"></a>Numerics vs. Arrays</h2></div></div></div><p>One of the major reasons why FORTRAN can chew through numbers so well
- is that it is defined to be free of pointer aliasing, an assumption
- that C89 is not allowed to make, and neither is C++98. C99 adds a new
- keyword, <code class="code">restrict</code>, to apply to individual pointers. The
- C++ solution is contained in the library rather than the language
- (although many vendors can be expected to add this to their compilers
- as an extension).
- </p><p>That library solution is a set of two classes, five template classes,
- and "a whole bunch" of functions. The classes are required
- to be free of pointer aliasing, so compilers can optimize the
- daylights out of them the same way that they have been for FORTRAN.
- They are collectively called <code class="code">valarray</code>, although strictly
- speaking this is only one of the five template classes, and they are
- designed to be familiar to people who have worked with the BLAS
- libraries before.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="generalized_numeric_operations.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="numerics.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt10ch23s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 22. Generalized Operations </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> C99</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/pairs.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/pairs.html
deleted file mode 100644
index 608344cfb..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/pairs.html
+++ /dev/null
@@ -1,42 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 10. Pairs</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="utilities.html" title="Part IV.  Utilities" /><link rel="prev" href="functors.html" title="Chapter 9. Functors" /><link rel="next" href="memory.html" title="Chapter 11. Memory" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 10. Pairs</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="functors.html">Prev</a> </td><th width="60%" align="center">Part IV. 
- Utilities
-
-</th><td width="20%" align="right"> <a accesskey="n" href="memory.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.util.pairs"></a>Chapter 10. Pairs</h2></div></div></div><p>The <code class="code">pair&lt;T1,T2&gt;</code> is a simple and handy way to
- carry around a pair of objects. One is of type T1, and another of
- type T2; they may be the same type, but you don't get anything
- extra if they are. The two members can be accessed directly, as
- <code class="code">.first</code> and <code class="code">.second</code>.
- </p><p>Construction is simple. The default ctor initializes each member
- with its respective default ctor. The other simple ctor,
- </p><pre class="programlisting">
- pair (const T1&amp; x, const T2&amp; y);
- </pre><p>does what you think it does, <code class="code">first</code> getting <code class="code">x</code>
- and <code class="code">second</code> getting <code class="code">y</code>.
- </p><p>There is a copy constructor, but it requires that your compiler
- handle member function templates:
- </p><pre class="programlisting">
- template &lt;class U, class V&gt; pair (const pair&lt;U,V&gt;&amp; p);
- </pre><p>The compiler will convert as necessary from U to T1 and from
- V to T2 in order to perform the respective initializations.
- </p><p>The comparison operators are done for you. Equality
- of two <code class="code">pair&lt;T1,T2&gt;</code>s is defined as both <code class="code">first</code>
- members comparing equal and both <code class="code">second</code> members comparing
- equal; this simply delegates responsibility to the respective
- <code class="code">operator==</code> functions (for types like MyClass) or builtin
- comparisons (for types like int, char, etc).
- </p><p>
- The less-than operator is a bit odd the first time you see it. It
- is defined as evaluating to:
- </p><pre class="programlisting">
- x.first &lt; y.first ||
- ( !(y.first &lt; x.first) &amp;&amp; x.second &lt; y.second )
- </pre><p>The other operators are not defined using the <code class="code">rel_ops</code>
- functions above, but their semantics are the same.
- </p><p>Finally, there is a template function called <code class="function">make_pair</code>
- that takes two references-to-const objects and returns an
- instance of a pair instantiated on their respective types:
- </p><pre class="programlisting">
- pair&lt;int,MyClass&gt; p = make_pair(4,myobject);
- </pre></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="functors.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="utilities.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="memory.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 9. Functors </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 11. Memory</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/parallel_mode.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/parallel_mode.html
deleted file mode 100644
index e757819ed..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/parallel_mode.html
+++ /dev/null
@@ -1,24 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 31. Parallel Mode</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; C++&#10; , &#10; library&#10; , &#10; parallel&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="extensions.html" title="Part XII.  Extensions" /><link rel="prev" href="bk01pt12ch30s04.html" title="Design" /><link rel="next" href="bk01pt12ch31s02.html" title="Semantics" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 31. Parallel Mode</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt12ch30s04.html">Prev</a> </td><th width="60%" align="center">Part XII. 
- Extensions
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt12ch31s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.ext.parallel_mode"></a>Chapter 31. Parallel Mode</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="parallel_mode.html#manual.ext.parallel_mode.intro">Intro</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch31s02.html">Semantics</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch31s03.html">Using</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch31s03.html#parallel_mode.using.prereq_flags">Prerequisite Compiler Flags</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch31s03.html#parallel_mode.using.parallel_mode">Using Parallel Mode</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch31s03.html#parallel_mode.using.specific">Using Specific Parallel Components</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch31s04.html">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch31s04.html#manual.ext.parallel_mode.design.intro">Interface Basics</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch31s04.html#manual.ext.parallel_mode.design.tuning">Configuration and Tuning</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch31s04.html#manual.ext.parallel_mode.design.impl">Implementation Namespaces</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch31s05.html">Testing</a></span></dt><dt><span class="bibliography"><a href="parallel_mode.html#parallel_mode.biblio">Bibliography</a></span></dt></dl></div><p> The libstdc++ parallel mode is an experimental parallel
-implementation of many algorithms the C++ Standard Library.
-</p><p>
-Several of the standard algorithms, for instance
-<code class="function">std::sort</code>, are made parallel using OpenMP
-annotations. These parallel mode constructs and can be invoked by
-explicit source declaration or by compiling existing sources with a
-specific compiler flag.
-</p><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.parallel_mode.intro"></a>Intro</h2></div></div></div><p>The following library components in the include
-<code class="filename">numeric</code> are included in the parallel mode:</p><div class="itemizedlist"><ul type="disc"><li><p><code class="function">std::accumulate</code></p></li><li><p><code class="function">std::adjacent_difference</code></p></li><li><p><code class="function">std::inner_product</code></p></li><li><p><code class="function">std::partial_sum</code></p></li></ul></div><p>The following library components in the include
-<code class="filename">algorithm</code> are included in the parallel mode:</p><div class="itemizedlist"><ul type="disc"><li><p><code class="function">std::adjacent_find</code></p></li><li><p><code class="function">std::count</code></p></li><li><p><code class="function">std::count_if</code></p></li><li><p><code class="function">std::equal</code></p></li><li><p><code class="function">std::find</code></p></li><li><p><code class="function">std::find_if</code></p></li><li><p><code class="function">std::find_first_of</code></p></li><li><p><code class="function">std::for_each</code></p></li><li><p><code class="function">std::generate</code></p></li><li><p><code class="function">std::generate_n</code></p></li><li><p><code class="function">std::lexicographical_compare</code></p></li><li><p><code class="function">std::mismatch</code></p></li><li><p><code class="function">std::search</code></p></li><li><p><code class="function">std::search_n</code></p></li><li><p><code class="function">std::transform</code></p></li><li><p><code class="function">std::replace</code></p></li><li><p><code class="function">std::replace_if</code></p></li><li><p><code class="function">std::max_element</code></p></li><li><p><code class="function">std::merge</code></p></li><li><p><code class="function">std::min_element</code></p></li><li><p><code class="function">std::nth_element</code></p></li><li><p><code class="function">std::partial_sort</code></p></li><li><p><code class="function">std::partition</code></p></li><li><p><code class="function">std::random_shuffle</code></p></li><li><p><code class="function">std::set_union</code></p></li><li><p><code class="function">std::set_intersection</code></p></li><li><p><code class="function">std::set_symmetric_difference</code></p></li><li><p><code class="function">std::set_difference</code></p></li><li><p><code class="function">std::sort</code></p></li><li><p><code class="function">std::stable_sort</code></p></li><li><p><code class="function">std::unique_copy</code></p></li></ul></div></div><div class="bibliography"><div class="titlepage"><div><div><h2 class="title"><a id="parallel_mode.biblio"></a>Bibliography</h2></div></div></div><div class="biblioentry"><a id="id399845"></a><p><span class="title"><i>
- Parallelization of Bulk Operations for STL Dictionaries
- </i>. </span><span class="author"><span class="firstname">Johannes</span> <span class="surname">Singler</span>. </span><span class="author"><span class="firstname">Leonor</span> <span class="surname">Frias</span>. </span><span class="copyright">Copyright © 2007 . </span><span class="publisher"><span class="publishername">
- Workshop on Highly Parallel Processing on a Chip (HPPC) 2007. (LNCS)
- . </span></span></p></div><div class="biblioentry"><a id="id418415"></a><p><span class="title"><i>
- The Multi-Core Standard Template Library
- </i>. </span><span class="author"><span class="firstname">Johannes</span> <span class="surname">Singler</span>. </span><span class="author"><span class="firstname">Peter</span> <span class="surname">Sanders</span>. </span><span class="author"><span class="firstname">Felix</span> <span class="surname">Putze</span>. </span><span class="copyright">Copyright © 2007 . </span><span class="publisher"><span class="publishername">
- Euro-Par 2007: Parallel Processing. (LNCS 4641)
- . </span></span></p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt12ch30s04.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt12ch31s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Design </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Semantics</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/sequences.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/sequences.html
deleted file mode 100644
index 00d5255d5..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/sequences.html
+++ /dev/null
@@ -1,43 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 16. Sequences</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="containers.html" title="Part VII.  Containers" /><link rel="prev" href="containers.html" title="Part VII.  Containers" /><link rel="next" href="vector.html" title="vector" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 16. Sequences</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="containers.html">Prev</a> </td><th width="60%" align="center">Part VII. 
- Containers
-
-</th><td width="20%" align="right"> <a accesskey="n" href="vector.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.containers.sequences"></a>Chapter 16. Sequences</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="sequences.html#containers.sequences.list">list</a></span></dt><dd><dl><dt><span class="sect2"><a href="sequences.html#sequences.list.size">list::size() is O(n)</a></span></dt></dl></dd><dt><span class="sect1"><a href="vector.html">vector</a></span></dt><dd><dl><dt><span class="sect2"><a href="vector.html#sequences.vector.management">Space Overhead Management</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="containers.sequences.list"></a>list</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="sequences.list.size"></a>list::size() is O(n)</h3></div></div></div><p>
- Yes it is, and that's okay. This is a decision that we preserved
- when we imported SGI's STL implementation. The following is
- quoted from <a class="ulink" href="http://www.sgi.com/tech/stl/FAQ.html" target="_top">their FAQ</a>:
- </p><div class="blockquote"><blockquote class="blockquote"><p>
- The size() member function, for list and slist, takes time
- proportional to the number of elements in the list. This was a
- deliberate tradeoff. The only way to get a constant-time
- size() for linked lists would be to maintain an extra member
- variable containing the list's size. This would require taking
- extra time to update that variable (it would make splice() a
- linear time operation, for example), and it would also make the
- list larger. Many list algorithms don't require that extra
- word (algorithms that do require it might do better with
- vectors than with lists), and, when it is necessary to maintain
- an explicit size count, it's something that users can do
- themselves.
- </p><p>
- This choice is permitted by the C++ standard. The standard says
- that size() “<span class="quote">should</span>” be constant time, and
- “<span class="quote">should</span>” does not mean the same thing as
- “<span class="quote">shall</span>”. This is the officially recommended ISO
- wording for saying that an implementation is supposed to do
- something unless there is a good reason not to.
- </p><p>
- One implication of linear time size(): you should never write
- </p><pre class="programlisting">
- if (L.size() == 0)
- ...
- </pre><p>
- Instead, you should write
- </p><pre class="programlisting">
- if (L.empty())
- ...
- </pre></blockquote></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="containers.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="containers.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="vector.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part VII. 
- Containers
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> vector</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/setup.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/setup.html
deleted file mode 100644
index f1e45ae08..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/setup.html
+++ /dev/null
@@ -1,101 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 2. Setup</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="intro.html" title="Part I.  Introduction" /><link rel="prev" href="bugs.html" title="Bugs" /><link rel="next" href="configure.html" title="Configure" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 2. Setup</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bugs.html">Prev</a> </td><th width="60%" align="center">Part I. 
- Introduction
-
-</th><td width="20%" align="right"> <a accesskey="n" href="configure.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.intro.setup"></a>Chapter 2. Setup</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="setup.html#manual.intro.setup.prereq">Prerequisites</a></span></dt><dt><span class="sect1"><a href="configure.html">Configure</a></span></dt><dt><span class="sect1"><a href="make.html">Make</a></span></dt><dt><span class="sect1"><a href="test.html">Test</a></span></dt><dd><dl><dt><span class="sect2"><a href="test.html#test.organization">Organization</a></span></dt><dt><span class="sect2"><a href="test.html#test.run">Running the Testsuite</a></span></dt><dt><span class="sect2"><a href="test.html#test.new_tests">Writing a new test case</a></span></dt><dt><span class="sect2"><a href="test.html#test.harness">Test Harness and Utilities</a></span></dt></dl></dd></dl></div><p>To transform libstdc++ sources into installed include files
- and properly built binaries useful for linking to other software is
- a multi-step process. Steps include getting the sources,
- configuring and building the sources, testing, and installation.
- </p><p>The general outline of commands is something like:
- </p><pre class="programlisting">
- <span class="emphasis"><em>get gcc sources</em></span>
- <span class="emphasis"><em>extract into gccsrcdir</em></span>
- mkdir <span class="emphasis"><em>gccbuilddir</em></span>
- cd <span class="emphasis"><em>gccbuilddir</em></span>
- <span class="emphasis"><em>gccsrcdir</em></span>/configure --prefix=<span class="emphasis"><em>destdir</em></span> --other-opts...
- make
- make check
- make install
- </pre><p>
- Each step is described in more detail in the following sections.
- </p><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.setup.prereq"></a>Prerequisites</h2></div></div></div><p>
- Because libstdc++ is part of GCC, the primary source for
- installation instructions is
- <a class="ulink" href="http://gcc.gnu.org/install/" target="_top">the GCC install page</a>.
- In particular, list of prerequisite software needed to build the library
- <a class="ulink" href="http://gcc.gnu.org/install/prerequisites.html" target="_top">
- starts with those requirements.</a> The same pages also list
- the tools you will need if you wish to modify the source.
-</p><p>
- Additional data is given here only where it applies to libstdc++.
- </p><p>As of GCC 4.0.1 the minimum version of binutils required to build
- libstdc++ is <code class="code">2.15.90.0.1.1</code>. You can get snapshots
- (as well as releases) of binutils from
- <a class="ulink" href="ftp://sources.redhat.com/pub/binutils" target="_top">
- ftp://sources.redhat.com/pub/binutils</a>.
- Older releases of libstdc++ do not require such a recent version,
- but to take full advantage of useful space-saving features and
- bug-fixes you should use a recent binutils whenever possible.
- The configure process will automatically detect and use these
- features if the underlying support is present.
- </p><p>
- Finally, a few system-specific requirements:
- </p><div class="variablelist"><dl><dt><span class="term">linux</span></dt><dd><p>
- If gcc 3.1.0 or later on is being used on linux, an attempt
- will be made to use "C" library functionality necessary for
- C++ named locale support. For gcc 3.2.1 and later, this
- means that glibc 2.2.5 or later is required and the "C"
- library de_DE locale information must be installed.
- </p><p>
- Note however that the sanity checks involving the de_DE
- locale are skipped when an explicit --enable-clocale=gnu
- configure option is used: only the basic checks are carried
- out, defending against misconfigurations.
- </p><p>
- If the 'gnu' locale model is being used, the following
- locales are used and tested in the libstdc++ testsuites.
- The first column is the name of the locale, the second is
- the character set it is expected to use.
- </p><pre class="programlisting">
-de_DE ISO-8859-1
-de_DE@euro ISO-8859-15
-en_HK ISO-8859-1
-en_PH ISO-8859-1
-en_US ISO-8859-1
-en_US.ISO-8859-1 ISO-8859-1
-en_US.ISO-8859-15 ISO-8859-15
-en_US.UTF-8 UTF-8
-es_ES ISO-8859-1
-es_MX ISO-8859-1
-fr_FR ISO-8859-1
-fr_FR@euro ISO-8859-15
-is_IS UTF-8
-it_IT ISO-8859-1
-ja_JP.eucjp EUC-JP
-se_NO.UTF-8 UTF-8
-ta_IN UTF-8
-zh_TW BIG5
-</pre><p>Failure to have the underlying "C" library locale
- information installed will mean that C++ named locales for the
- above regions will not work: because of this, the libstdc++
- testsuite will skip the named locale tests. If this isn't an
- issue, don't worry about it. If named locales are needed, the
- underlying locale information must be installed. Note that
- rebuilding libstdc++ after the "C" locales are installed is not
- necessary.
- </p><p>
- To install support for locales, do only one of the following:
- </p><div class="itemizedlist"><ul type="disc"><li><p>install all locales</p><div class="itemizedlist"><ul type="circle"><li><p>with RedHat Linux:
- </p><p> <code class="code"> export LC_ALL=C </code>
- </p><p> <code class="code"> rpm -e glibc-common --nodeps </code>
- </p><p>
- <code class="code"> rpm -i --define "_install_langs all"
- glibc-common-2.2.5-34.i386.rpm
- </code>
- </p></li><li><p>
- Instructions for other operating systems solicited.
- </p></li></ul></div></li><li><p>install just the necessary locales</p><div class="itemizedlist"><ul type="circle"><li><p>with Debian Linux:</p><p> Add the above list, as shown, to the file
- <code class="code">/etc/locale.gen</code> </p><p> run <code class="code">/usr/sbin/locale-gen</code> </p></li><li><p>on most Unix-like operating systems:</p><p><code class="code"> localedef -i de_DE -f ISO-8859-1 de_DE </code></p><p>(repeat for each entry in the above list) </p></li><li><p>
- Instructions for other operating systems solicited.
- </p></li></ul></div></li></ul></div></dd></dl></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bugs.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="intro.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="configure.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Bugs </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Configure</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/shared_ptr.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/shared_ptr.html
deleted file mode 100644
index c5e9616a7..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/shared_ptr.html
+++ /dev/null
@@ -1,304 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>shared_ptr</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; shared_ptr&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="memory.html" title="Chapter 11. Memory" /><link rel="prev" href="auto_ptr.html" title="auto_ptr" /><link rel="next" href="traits.html" title="Chapter 12. Traits" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">shared_ptr</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="auto_ptr.html">Prev</a> </td><th width="60%" align="center">Chapter 11. Memory</th><td width="20%" align="right"> <a accesskey="n" href="traits.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.util.memory.shared_ptr"></a>shared_ptr</h2></div></div></div><p>
-The shared_ptr class template stores a pointer, usually obtained via new,
-and implements shared ownership semantics.
-</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="shared_ptr.req"></a>Requirements</h3></div></div></div><p>
- </p><p>
- The standard deliberately doesn't require a reference-counted
- implementation, allowing other techniques such as a
- circular-linked-list.
- </p><p>
- At the time of writing the C++0x working paper doesn't mention how
- threads affect shared_ptr, but it is likely to follow the existing
- practice set by <code class="classname">boost::shared_ptr</code>. The
- shared_ptr in libstdc++ is derived from Boost's, so the same rules
- apply.
- </p><p>
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="shared_ptr.design_issues"></a>Design Issues</h3></div></div></div><p>
-The <code class="classname">shared_ptr</code> code is kindly donated to GCC by the Boost
-project and the original authors of the code. The basic design and
-algorithms are from Boost, the notes below describe details specific to
-the GCC implementation. Names have been uglified in this implementation,
-but the design should be recognisable to anyone familiar with the Boost
-1.32 shared_ptr.
- </p><p>
-The basic design is an abstract base class, <code class="code">_Sp_counted_base</code> that
-does the reference-counting and calls virtual functions when the count
-drops to zero.
-Derived classes override those functions to destroy resources in a context
-where the correct dynamic type is known. This is an application of the
-technique known as type erasure.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="shared_ptr.impl"></a>Implementation</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id400915"></a>Class Hierarchy</h4></div></div></div><p>
-A <code class="classname">shared_ptr&lt;T&gt;</code> contains a pointer of
-type <span class="type">T*</span> and an object of type
-<code class="classname">__shared_count</code>. The shared_count contains a
-pointer of type <span class="type">_Sp_counted_base*</span> which points to the
-object that maintains the reference-counts and destroys the managed
-resource.
- </p><div class="variablelist"><dl><dt><span class="term"><code class="classname">_Sp_counted_base&lt;Lp&gt;</code></span></dt><dd><p>
-The base of the hierarchy is parameterized on the lock policy alone.
-_Sp_counted_base doesn't depend on the type of pointer being managed,
-it only maintains the reference counts and calls virtual functions when
-the counts drop to zero. The managed object is destroyed when the last
-strong reference is dropped, but the _Sp_counted_base itself must exist
-until the last weak reference is dropped.
- </p></dd><dt><span class="term"><code class="classname">_Sp_counted_base_impl&lt;Ptr, Deleter, Lp&gt;</code></span></dt><dd><p>
-Inherits from _Sp_counted_base and stores a pointer of type <span class="type">Ptr</span>
-and a deleter of type <code class="code">Deleter</code>. <code class="code">_Sp_deleter</code> is
-used when the user doesn't supply a custom deleter. Unlike Boost's, this
-default deleter is not "checked" because GCC already issues a warning if
-<code class="function">delete</code> is used with an incomplete type.
-This is the only derived type used by <code class="classname">shared_ptr&lt;Ptr&gt;</code>
-and it is never used by <code class="classname">shared_ptr</code>, which uses one of
-the following types, depending on how the shared_ptr is constructed.
- </p></dd><dt><span class="term"><code class="classname">_Sp_counted_ptr&lt;Ptr, Lp&gt;</code></span></dt><dd><p>
-Inherits from _Sp_counted_base and stores a pointer of type <span class="type">Ptr</span>,
-which is passed to <code class="function">delete</code> when the last reference is dropped.
-This is the simplest form and is used when there is no custom deleter or
-allocator.
- </p></dd><dt><span class="term"><code class="classname">_Sp_counted_deleter&lt;Ptr, Deleter, Alloc&gt;</code></span></dt><dd><p>
-Inherits from _Sp_counted_ptr and adds support for custom deleter and
-allocator. Empty Base Optimization is used for the allocator. This class
-is used even when the user only provides a custom deleter, in which case
-<code class="classname">allocator</code> is used as the allocator.
- </p></dd><dt><span class="term"><code class="classname">_Sp_counted_ptr_inplace&lt;Tp, Alloc, Lp&gt;</code></span></dt><dd><p>
-Used by <code class="code">allocate_shared</code> and <code class="code">make_shared</code>.
-Contains aligned storage to hold an object of type <span class="type">Tp</span>,
-which is constructed in-place with placement <code class="function">new</code>.
-Has a variadic template constructor allowing any number of arguments to
-be forwarded to <span class="type">Tp</span>'s constructor.
-Unlike the other <code class="classname">_Sp_counted_*</code> classes, this one is parameterized on the
-type of object, not the type of pointer; this is purely a convenience
-that simplifies the implementation slightly.
- </p></dd></dl></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id407287"></a>Thread Safety</h4></div></div></div><p>
-The interface of <code class="classname">tr1::shared_ptr</code> was extended for C++0x
-with support for rvalue-references and the other features from
-N2351. As with other libstdc++ headers shared by TR1 and C++0x,
-boost_shared_ptr.h uses conditional compilation, based on the macros
-<code class="constant">_GLIBCXX_INCLUDE_AS_CXX0X</code> and
-<code class="constant">_GLIBCXX_INCLUDE_AS_TR1</code>, to enable and disable
-features.
- </p><p>
-C++0x-only features are: rvalue-ref/move support, allocator support,
-aliasing constructor, make_shared &amp; allocate_shared. Additionally,
-the constructors taking <code class="classname">auto_ptr</code> parameters are
-deprecated in C++0x mode.
- </p><p>
-The
-<a class="ulink" href="http://boost.org/libs/smart_ptr/shared_ptr.htm#ThreadSafety" target="_top">Thread
-Safety</a> section of the Boost shared_ptr documentation says "shared_ptr
-objects offer the same level of thread safety as built-in types."
-The implementation must ensure that concurrent updates to separate shared_ptr
-instances are correct even when those instances share a reference count e.g.
-</p><pre class="programlisting">
-shared_ptr&lt;A&gt; a(new A);
-shared_ptr&lt;A&gt; b(a);
-
-// Thread 1 // Thread 2
- a.reset(); b.reset();
-</pre><p>
-The dynamically-allocated object must be destroyed by exactly one of the
-threads. Weak references make things even more interesting.
-The shared state used to implement shared_ptr must be transparent to the
-user and invariants must be preserved at all times.
-The key pieces of shared state are the strong and weak reference counts.
-Updates to these need to be atomic and visible to all threads to ensure
-correct cleanup of the managed resource (which is, after all, shared_ptr's
-job!)
-On multi-processor systems memory synchronisation may be needed so that
-reference-count updates and the destruction of the managed resource are
-race-free.
-</p><p>
-The function <code class="function">_Sp_counted_base::_M_add_ref_lock()</code>, called when
-obtaining a shared_ptr from a weak_ptr, has to test if the managed
-resource still exists and either increment the reference count or throw
-<code class="classname">bad_weak_ptr</code>.
-In a multi-threaded program there is a potential race condition if the last
-reference is dropped (and the managed resource destroyed) between testing
-the reference count and incrementing it, which could result in a shared_ptr
-pointing to invalid memory.
-</p><p>
-The Boost shared_ptr (as used in GCC) features a clever lock-free
-algorithm to avoid the race condition, but this relies on the
-processor supporting an atomic <span class="emphasis"><em>Compare-And-Swap</em></span>
-instruction. For other platforms there are fall-backs using mutex
-locks. Boost (as of version 1.35) includes several different
-implementations and the preprocessor selects one based on the
-compiler, standard library, platform etc. For the version of
-shared_ptr in libstdc++ the compiler and library are fixed, which
-makes things much simpler: we have an atomic CAS or we don't, see Lock
-Policy below for details.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id402403"></a>Selecting Lock Policy</h4></div></div></div><p>
- </p><p>
-There is a single <code class="classname">_Sp_counted_base</code> class,
-which is a template parameterized on the enum
-<span class="type">__gnu_cxx::_Lock_policy</span>. The entire family of classes is
-parameterized on the lock policy, right up to
-<code class="classname">__shared_ptr</code>, <code class="classname">__weak_ptr</code> and
-<code class="classname">__enable_shared_from_this</code>. The actual
-<code class="classname">std::shared_ptr</code> class inherits from
-<code class="classname">__shared_ptr</code> with the lock policy parameter
-selected automatically based on the thread model and platform that
-libstdc++ is configured for, so that the best available template
-specialization will be used. This design is necessary because it would
-not be conforming for <code class="classname">shared_ptr</code> to have an
-extra template parameter, even if it had a default value. The
-available policies are:
- </p><div class="orderedlist"><ol type="1"><li><p>
- <span class="type">_S_Atomic</span>
- </p><p>
-Selected when GCC supports a builtin atomic compare-and-swap operation
-on the target processor (see <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html" target="_top">Atomic
-Builtins</a>.) The reference counts are maintained using a lock-free
-algorithm and GCC's atomic builtins, which provide the required memory
-synchronisation.
- </p></li><li><p>
- <span class="type">_S_Mutex</span>
- </p><p>
-The _Sp_counted_base specialization for this policy contains a mutex,
-which is locked in add_ref_lock(). This policy is used when GCC's atomic
-builtins aren't available so explicit memory barriers are needed in places.
- </p></li><li><p>
- <span class="type">_S_Single</span>
- </p><p>
-This policy uses a non-reentrant add_ref_lock() with no locking. It is
-used when libstdc++ is built without <code class="literal">--enable-threads</code>.
- </p></li></ol></div><p>
- For all three policies, reference count increments and
- decrements are done via the functions in
- <code class="filename">ext/atomicity.h</code>, which detect if the program
- is multi-threaded. If only one thread of execution exists in
- the program then less expensive non-atomic operations are used.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id406621"></a>Dual C++0x and TR1 Implementation</h4></div></div></div><p>
-The classes derived from <code class="classname">_Sp_counted_base</code> (see Class Hierarchy
-below) and <code class="classname">__shared_count</code> are implemented separately for C++0x
-and TR1, in <code class="filename">bits/boost_sp_shared_count.h</code> and
-<code class="filename">tr1/boost_sp_shared_count.h</code> respectively. All other classes
-including <code class="classname">_Sp_counted_base</code> are shared by both implementations.
-</p><p>
-The TR1 implementation is considered relatively stable, so is unlikely to
-change unless bug fixes require it. If the code that is common to both
-C++0x and TR1 modes needs to diverge further then it might be necessary to
-duplicate additional classes and only make changes to the C++0x versions.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id396482"></a>Related functions and classes</h4></div></div></div><div class="variablelist"><dl><dt><span class="term"><code class="code">dynamic_pointer_cast</code>, <code class="code">static_pointer_cast</code>,
-<code class="code">const_pointer_cast</code></span></dt><dd><p>
-As noted in N2351, these functions can be implemented non-intrusively using
-the alias constructor. However the aliasing constructor is only available
-in C++0x mode, so in TR1 mode these casts rely on three non-standard
-constructors in shared_ptr and __shared_ptr.
-In C++0x mode these constructors and the related tag types are not needed.
- </p></dd><dt><span class="term"><code class="code">enable_shared_from_this</code></span></dt><dd><p>
-The clever overload to detect a base class of type
-<code class="code">enable_shared_from_this</code> comes straight from Boost.
-There is an extra overload for <code class="code">__enable_shared_from_this</code> to
-work smoothly with <code class="code">__shared_ptr&lt;Tp, Lp&gt;</code> using any lock
-policy.
- </p></dd><dt><span class="term"><code class="code">make_shared</code>, <code class="code">allocate_shared</code></span></dt><dd><p>
-<code class="code">make_shared</code> simply forwards to <code class="code">allocate_shared</code>
-with <code class="code">std::allocator</code> as the allocator.
-Although these functions can be implemented non-intrusively using the
-alias constructor, if they have access to the implementation then it is
-possible to save storage and reduce the number of heap allocations. The
-newly constructed object and the _Sp_counted_* can be allocated in a single
-block and the standard says implementations are "encouraged, but not required,"
-to do so. This implementation provides additional non-standard constructors
-(selected with the type <code class="code">_Sp_make_shared_tag</code>) which create an
-object of type <code class="code">_Sp_counted_ptr_inplace</code> to hold the new object.
-The returned <code class="code">shared_ptr&lt;A&gt;</code> needs to know the address of the
-new <code class="code">A</code> object embedded in the <code class="code">_Sp_counted_ptr_inplace</code>,
-but it has no way to access it.
-This implementation uses a "covert channel" to return the address of the
-embedded object when <code class="code">get_deleter&lt;_Sp_make_shared_tag&gt;()</code>
-is called. Users should not try to use this.
-As well as the extra constructors, this implementation also needs some
-members of _Sp_counted_deleter to be protected where they could otherwise
-be private.
- </p></dd></dl></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="shared_ptr.using"></a>Use</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id397112"></a>Examples</h4></div></div></div><p>
- Examples of use can be found in the testsuite, under
- <code class="filename">testsuite/tr1/2_general_utilities/shared_ptr</code>.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id403999"></a>Unresolved Issues</h4></div></div></div><p>
- The resolution to C++ Standard Library issue <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#674" target="_top">674</a>,
- "shared_ptr interface changes for consistency with N1856" will
- need to be implemented after it is accepted into the working
- paper. Issue <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#743" target="_top">743</a>
- might also require changes.
- </p><p>
- The <span class="type">_S_single</span> policy uses atomics when used in MT
- code, because it uses the same dispatcher functions that check
- <code class="function">__gthread_active_p()</code>. This could be
- addressed by providing template specialisations for some members
- of <code class="classname">_Sp_counted_base&lt;_S_single&gt;</code>.
- </p><p>
- Unlike Boost, this implementation does not use separate classes
- for the pointer+deleter and pointer+deleter+allocator cases in
- C++0x mode, combining both into _Sp_counted_deleter and using
- <code class="classname">allocator</code> when the user doesn't specify
- an allocator. If it was found to be beneficial an additional
- class could easily be added. With the current implementation,
- the _Sp_counted_deleter and __shared_count constructors taking a
- custom deleter but no allocator are technically redundant and
- could be removed, changing callers to always specify an
- allocator. If a separate pointer+deleter class was added the
- __shared_count constructor would be needed, so it has been kept
- for now.
- </p><p>
- The hack used to get the address of the managed object from
- <code class="function">_Sp_counted_ptr_inplace::_M_get_deleter()</code>
- is accessible to users. This could be prevented if
- <code class="function">get_deleter&lt;_Sp_make_shared_tag&gt;()</code>
- always returned NULL, since the hack only needs to work at a
- lower level, not in the public API. This wouldn't be difficult,
- but hasn't been done since there is no danger of accidental
- misuse: users already know they are relying on unsupported
- features if they refer to implementation details such as
- _Sp_make_shared_tag.
- </p><p>
- tr1::_Sp_deleter could be a private member of tr1::__shared_count but it
- would alter the ABI.
- </p><p>
- Exposing the alias constructor in TR1 mode could simplify the
- *_pointer_cast functions. Constructor could be private in TR1
- mode, with the cast functions as friends.
- </p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="shared_ptr.ack"></a>Acknowledgments</h3></div></div></div><p>
- The original authors of the Boost shared_ptr, which is really nice
- code to work with, Peter Dimov in particular for his help and
- invaluable advice on thread safety. Phillip Jordan and Paolo
- Carlini for the lock policy implementation.
- </p></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="shared_ptr.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="id399126"></a><p>[<abbr class="abbrev">
- n2351
- </abbr>] <span class="title"><i>
- Improving shared_ptr for C++0x, Revision 2
- </i>. </span><span class="subtitle">
- N2351
- . </span><span class="biblioid">
- <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id406438"></a><p>[<abbr class="abbrev">
- n2456
- </abbr>] <span class="title"><i>
- C++ Standard Library Active Issues List (Revision R52)
- </i>. </span><span class="subtitle">
- N2456
- . </span><span class="biblioid">
- <a class="ulink" href="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2456.html" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id406462"></a><p>[<abbr class="abbrev">
- n2461
- </abbr>] <span class="title"><i>
- Working Draft, Standard for Programming Language C++
- </i>. </span><span class="subtitle">
- N2461
- . </span><span class="biblioid">
- <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf" target="_top">
- </a>
- . </span></p></div><div class="biblioentry"><a id="id413273"></a><p>[<abbr class="abbrev">
- boostshared_ptr
- </abbr>] <span class="title"><i>
- Boost C++ Libraries documentation - shared_ptr class template
- </i>. </span><span class="subtitle">
- N2461
- . </span><span class="biblioid">
- <a class="ulink" href="http://boost.org/libs/smart_ptr/shared_ptr.htm" target="_top">shared_ptr
- </a>
- . </span></p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="auto_ptr.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="memory.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="traits.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">auto_ptr </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 12. Traits</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/source_code_style.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/source_code_style.html
deleted file mode 100644
index d8737aebb..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/source_code_style.html
+++ /dev/null
@@ -1,588 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Coding Style</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_contributing.html" title="Appendix A.  Contributing" /><link rel="prev" href="source_organization.html" title="Directory Layout and Source Conventions" /><link rel="next" href="documentation_style.html" title="Documentation Style" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Coding Style</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="source_organization.html">Prev</a> </td><th width="60%" align="center">Appendix A. 
- Contributing
-
-</th><td width="20%" align="right"> <a accesskey="n" href="documentation_style.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contrib.coding_style"></a>Coding Style</h2></div></div></div><p>
- </p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="coding_style.bad_identifiers"></a>Bad Identifiers</h3></div></div></div><p>
- Identifiers that conflict and should be avoided.
- </p><div class="literallayout"><p><br />
-      This is the list of names “<span class="quote">reserved to the<br />
-      implementation</span>” that have been claimed by certain<br />
-      compilers and system headers of interest, and should not be used<br />
-      in the library. It will grow, of course.  We generally are<br />
-      interested in names that are not all-caps, except for those like<br />
-      "_T"<br />
-<br />
-      For Solaris:<br />
-      _B<br />
-      _C<br />
-      _L<br />
-      _N<br />
-      _P<br />
-      _S<br />
-      _U<br />
-      _X<br />
-      _E1<br />
-      ..<br />
-      _E24<br />
-<br />
-      Irix adds:<br />
-      _A<br />
-      _G<br />
-<br />
-      MS adds:<br />
-      _T<br />
-<br />
-      BSD adds:<br />
-      __used<br />
-      __unused<br />
-      __inline<br />
-      _Complex<br />
-      __istype<br />
-      __maskrune<br />
-      __tolower<br />
-      __toupper<br />
-      __wchar_t<br />
-      __wint_t<br />
-      _res<br />
-      _res_ext<br />
-      __tg_*<br />
-<br />
-      SPU adds:<br />
-      __ea<br />
-<br />
-      For GCC:<br />
-<br />
-      [Note that this list is out of date. It applies to the old<br />
-      name-mangling; in G++ 3.0 and higher a different name-mangling is<br />
-      used. In addition, many of the bugs relating to G++ interpreting<br />
-      these names as operators have been fixed.]<br />
-<br />
-      The full set of __* identifiers (combined from gcc/cp/lex.c and<br />
-      gcc/cplus-dem.c) that are either old or new, but are definitely <br />
-      recognized by the demangler, is:<br />
-<br />
-      __aa<br />
-      __aad<br />
-      __ad<br />
-      __addr<br />
-      __adv<br />
-      __aer<br />
-      __als<br />
-      __alshift<br />
-      __amd<br />
-      __ami<br />
-      __aml<br />
-      __amu<br />
-      __aor<br />
-      __apl<br />
-      __array<br />
-      __ars<br />
-      __arshift<br />
-      __as<br />
-      __bit_and<br />
-      __bit_ior<br />
-      __bit_not<br />
-      __bit_xor<br />
-      __call<br />
-      __cl<br />
-      __cm<br />
-      __cn<br />
-      __co<br />
-      __component<br />
-      __compound<br />
-      __cond<br />
-      __convert<br />
-      __delete<br />
-      __dl<br />
-      __dv<br />
-      __eq<br />
-      __er<br />
-      __ge<br />
-      __gt<br />
-      __indirect<br />
-      __le<br />
-      __ls<br />
-      __lt<br />
-      __max<br />
-      __md<br />
-      __method_call<br />
-      __mi<br />
-      __min<br />
-      __minus<br />
-      __ml<br />
-      __mm<br />
-      __mn<br />
-      __mult<br />
-      __mx<br />
-      __ne<br />
-      __negate<br />
-      __new<br />
-      __nop<br />
-      __nt<br />
-      __nw<br />
-      __oo<br />
-      __op<br />
-      __or<br />
-      __pl<br />
-      __plus<br />
-      __postdecrement<br />
-      __postincrement<br />
-      __pp<br />
-      __pt<br />
-      __rf<br />
-      __rm<br />
-      __rs<br />
-      __sz<br />
-      __trunc_div<br />
-      __trunc_mod<br />
-      __truth_andif<br />
-      __truth_not<br />
-      __truth_orif<br />
-      __vc<br />
-      __vd<br />
-      __vn<br />
-<br />
-      SGI badnames:<br />
-      __builtin_alloca<br />
-      __builtin_fsqrt<br />
-      __builtin_sqrt<br />
-      __builtin_fabs<br />
-      __builtin_dabs<br />
-      __builtin_cast_f2i<br />
-      __builtin_cast_i2f<br />
-      __builtin_cast_d2ll<br />
-      __builtin_cast_ll2d<br />
-      __builtin_copy_dhi2i<br />
-      __builtin_copy_i2dhi<br />
-      __builtin_copy_dlo2i<br />
-      __builtin_copy_i2dlo<br />
-      __add_and_fetch<br />
-      __sub_and_fetch<br />
-      __or_and_fetch<br />
-      __xor_and_fetch<br />
-      __and_and_fetch<br />
-      __nand_and_fetch<br />
-      __mpy_and_fetch<br />
-      __min_and_fetch<br />
-      __max_and_fetch<br />
-      __fetch_and_add<br />
-      __fetch_and_sub<br />
-      __fetch_and_or<br />
-      __fetch_and_xor<br />
-      __fetch_and_and<br />
-      __fetch_and_nand<br />
-      __fetch_and_mpy<br />
-      __fetch_and_min<br />
-      __fetch_and_max<br />
-      __lock_test_and_set<br />
-      __lock_release<br />
-      __lock_acquire<br />
-      __compare_and_swap<br />
-      __synchronize<br />
-      __high_multiply<br />
-      __unix<br />
-      __sgi<br />
-      __linux__<br />
-      __i386__<br />
-      __i486__<br />
-      __cplusplus<br />
-      __embedded_cplusplus<br />
-      // long double conversion members mangled as __opr<br />
-      // http://gcc.gnu.org/ml/libstdc++/1999-q4/msg00060.html<br />
-      _opr<br />
-    </p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="coding_style.example"></a>By Example</h3></div></div></div><div class="literallayout"><p><br />
-      This library is written to appropriate C++ coding standards. As such,<br />
-      it is intended to precede the recommendations of the GNU Coding<br />
-      Standard, which can be referenced in full here:<br />
-<br />
-      http://www.gnu.org/prep/standards/standards.html#Formatting<br />
-<br />
-      The rest of this is also interesting reading, but skip the "Design<br />
-      Advice" part.<br />
-<br />
-      The GCC coding conventions are here, and are also useful:<br />
-      http://gcc.gnu.org/codingconventions.html<br />
-<br />
-      In addition, because it doesn't seem to be stated explicitly anywhere<br />
-      else, there is an 80 column source limit.<br />
-<br />
-      ChangeLog entries for member functions should use the<br />
-      classname::member function name syntax as follows:<br />
-<br />
-      1999-04-15  Dennis Ritchie  &lt;dr@att.com&gt;<br />
-<br />
-      * src/basic_file.cc (__basic_file::open): Fix thinko in<br />
-      _G_HAVE_IO_FILE_OPEN bits.<br />
-<br />
-      Notable areas of divergence from what may be previous local practice<br />
-      (particularly for GNU C) include:<br />
-<br />
-      01. Pointers and references<br />
-      char* p = "flop";<br />
-      char&amp; c = *p;<br />
-      -NOT-<br />
-      char *p = "flop";  // wrong<br />
-      char &amp;c = *p;      // wrong<br />
-      <br />
-      Reason: In C++, definitions are mixed with executable code. Here,       <br />
-      p is being initialized, not *p. This is near-universal<br />
-      practice among C++ programmers; it is normal for C hackers<br />
-      to switch spontaneously as they gain experience.<br />
-<br />
-      02. Operator names and parentheses<br />
-      operator==(type)<br />
-      -NOT-<br />
-      operator == (type)  // wrong<br />
-      <br />
-      Reason: The == is part of the function name. Separating<br />
-      it makes the declaration look like an expression. <br />
-<br />
-      03. Function names and parentheses<br />
-      void mangle()<br />
-      -NOT-<br />
-      void mangle ()  // wrong<br />
-<br />
-      Reason: no space before parentheses (except after a control-flow<br />
-      keyword) is near-universal practice for C++. It identifies the<br />
-      parentheses as the function-call operator or declarator, as <br />
-      opposed to an expression or other overloaded use of parentheses.<br />
-<br />
-      04. Template function indentation<br />
-      template&lt;typename T&gt;<br />
-      void <br />
-      template_function(args)<br />
-      { }<br />
-      -NOT-<br />
-      template&lt;class T&gt;<br />
-      void template_function(args) {};<br />
-      <br />
-      Reason: In class definitions, without indentation whitespace is<br />
-      needed both above and below the declaration to distinguish<br />
-      it visually from other members. (Also, re: "typename"<br />
-      rather than "class".)  T often could be int, which is <br />
-      not a class. ("class", here, is an anachronism.)<br />
-<br />
-      05. Template class indentation<br />
-      template&lt;typename _CharT, typename _Traits&gt;<br />
-      class basic_ios : public ios_base<br />
-      {<br />
-      public:<br />
-      // Types:<br />
-      };<br />
-      -NOT-<br />
-      template&lt;class _CharT, class _Traits&gt;<br />
-      class basic_ios : public ios_base<br />
-      {<br />
-      public:<br />
-      // Types:<br />
-      };<br />
-      -NOT-<br />
-      template&lt;class _CharT, class _Traits&gt;<br />
-      class basic_ios : public ios_base<br />
-      {<br />
-      public:<br />
-      // Types:<br />
-      };<br />
-<br />
-      06. Enumerators<br />
-      enum<br />
-      {<br />
-      space = _ISspace,<br />
-      print = _ISprint,<br />
-      cntrl = _IScntrl<br />
-      };<br />
-      -NOT-<br />
-      enum { space = _ISspace, print = _ISprint, cntrl = _IScntrl };<br />
-<br />
-      07. Member initialization lists<br />
-      All one line, separate from class name.<br />
-<br />
-      gribble::gribble() <br />
-      : _M_private_data(0), _M_more_stuff(0), _M_helper(0);<br />
-      { }<br />
-      -NOT-<br />
-      gribble::gribble() : _M_private_data(0), _M_more_stuff(0), _M_helper(0);<br />
-      { }<br />
-<br />
-      08. Try/Catch blocks<br />
-      try <br />
-      {<br />
-      //<br />
-      }   <br />
-      catch (...)<br />
-      {<br />
-      //<br />
-      }   <br />
-      -NOT-<br />
-      try {<br />
-      // <br />
-      } catch(...) { <br />
-      //<br />
-      }<br />
-<br />
-      09. Member functions declarations and definitions<br />
-      Keywords such as extern, static, export, explicit, inline, etc<br />
-      go on the line above the function name. Thus<br />
-<br />
-      virtual int   <br />
-      foo()<br />
-      -NOT-<br />
-      virtual int foo()<br />
-<br />
-      Reason: GNU coding conventions dictate return types for functions<br />
-      are on a separate line than the function name and parameter list<br />
-      for definitions. For C++, where we have member functions that can<br />
-      be either inline definitions or declarations, keeping to this<br />
-      standard allows all member function names for a given class to be<br />
-      aligned to the same margin, increasing readability.<br />
-<br />
-<br />
-      10. Invocation of member functions with "this-&gt;"<br />
-      For non-uglified names, use this-&gt;name to call the function.<br />
-<br />
-      this-&gt;sync()<br />
-      -NOT-<br />
-      sync()<br />
-<br />
-      Reason: Koenig lookup.<br />
-<br />
-      11. Namespaces<br />
-      namespace std<br />
-      {<br />
-      blah blah blah;<br />
-      } // namespace std<br />
-<br />
-      -NOT-<br />
-<br />
-      namespace std {<br />
-      blah blah blah;<br />
-      } // namespace std<br />
-<br />
-      12. Spacing under protected and private in class declarations:<br />
-      space above, none below<br />
-      i.e.<br />
-<br />
-      public:<br />
-      int foo;<br />
-<br />
-      -NOT-<br />
-      public:<br />
-      <br />
-      int foo;<br />
-<br />
-      13. Spacing WRT return statements.<br />
-      no extra spacing before returns, no parenthesis<br />
-      i.e.<br />
-<br />
-      }<br />
-      return __ret;<br />
-<br />
-      -NOT-<br />
-      }<br />
-<br />
-      return __ret;<br />
-<br />
-      -NOT-<br />
-<br />
-      }<br />
-      return (__ret);<br />
-<br />
-<br />
-      14. Location of global variables.<br />
-      All global variables of class type, whether in the "user visible"<br />
-      space (e.g., cin) or the implementation namespace, must be defined<br />
-      as a character array with the appropriate alignment and then later<br />
-      re-initialized to the correct value.<br />
-<br />
-      This is due to startup issues on certain platforms, such as AIX.<br />
-      For more explanation and examples, see src/globals.cc. All such<br />
-      variables should be contained in that file, for simplicity.<br />
-<br />
-      15. Exception abstractions<br />
-      Use the exception abstractions found in functexcept.h, which allow<br />
-      C++ programmers to use this library with -fno-exceptions. (Even if<br />
-      that is rarely advisable, it's a necessary evil for backwards<br />
-      compatibility.)<br />
-<br />
-      16. Exception error messages<br />
-      All start with the name of the function where the exception is<br />
-      thrown, and then (optional) descriptive text is added. Example:<br />
-<br />
-      __throw_logic_error(__N("basic_string::_S_construct NULL not valid"));<br />
-<br />
-      Reason: The verbose terminate handler prints out exception::what(),<br />
-      as well as the typeinfo for the thrown exception. As this is the<br />
-      default terminate handler, by putting location info into the<br />
-      exception string, a very useful error message is printed out for<br />
-      uncaught exceptions. So useful, in fact, that non-programmers can<br />
-      give useful error messages, and programmers can intelligently<br />
-      speculate what went wrong without even using a debugger.<br />
-<br />
-      17. The doxygen style guide to comments is a separate document,<br />
-      see index.<br />
-<br />
-      The library currently has a mixture of GNU-C and modern C++ coding<br />
-      styles. The GNU C usages will be combed out gradually.<br />
-<br />
-      Name patterns:<br />
-<br />
-      For nonstandard names appearing in Standard headers, we are constrained <br />
-      to use names that begin with underscores. This is called "uglification".<br />
-      The convention is:<br />
-<br />
-      Local and argument names:  __[a-z].*<br />
-<br />
-      Examples:  __count  __ix  __s1  <br />
-<br />
-      Type names and template formal-argument names: _[A-Z][^_].*<br />
-<br />
-      Examples:  _Helper  _CharT  _N <br />
-<br />
-      Member data and function names: _M_.*<br />
-<br />
-      Examples:  _M_num_elements  _M_initialize ()<br />
-<br />
-      Static data members, constants, and enumerations: _S_.*<br />
-<br />
-      Examples: _S_max_elements  _S_default_value<br />
-<br />
-      Don't use names in the same scope that differ only in the prefix, <br />
-      e.g. _S_top and _M_top. See BADNAMES for a list of forbidden names.<br />
-      (The most tempting of these seem to be and "_T" and "__sz".)<br />
-<br />
-      Names must never have "__" internally; it would confuse name<br />
-      unmanglers on some targets. Also, never use "__[0-9]", same reason.<br />
-<br />
-      --------------------------<br />
-<br />
-      [BY EXAMPLE]<br />
-      <br />
-      #ifndef  _HEADER_<br />
-      #define  _HEADER_ 1<br />
-<br />
-      namespace std<br />
-      {<br />
-      class gribble<br />
-      {<br />
-      public:<br />
-      gribble() throw();<br />
-<br />
-      gribble(const gribble&amp;);<br />
-<br />
-      explicit <br />
-      gribble(int __howmany);<br />
-<br />
-      gribble&amp; <br />
-      operator=(const gribble&amp;);<br />
-<br />
-      virtual <br />
-      ~gribble() throw ();<br />
-<br />
-      // Start with a capital letter, end with a period.<br />
-      inline void  <br />
-      public_member(const char* __arg) const;<br />
-<br />
-      // In-class function definitions should be restricted to one-liners.<br />
-      int <br />
-      one_line() { return 0 }<br />
-<br />
-      int <br />
-      two_lines(const char* arg) <br />
-      { return strchr(arg, 'a'); }<br />
-<br />
-      inline int <br />
-      three_lines();  // inline, but defined below.<br />
-<br />
-      // Note indentation.<br />
-      template&lt;typename _Formal_argument&gt;<br />
-      void <br />
-      public_template() const throw();<br />
-<br />
-      template&lt;typename _Iterator&gt;<br />
-      void <br />
-      other_template();<br />
-<br />
-      private:<br />
-      class _Helper;<br />
-<br />
-      int _M_private_data;<br />
-      int _M_more_stuff;<br />
-      _Helper* _M_helper;<br />
-      int _M_private_function();<br />
-<br />
-      enum _Enum <br />
-      { <br />
-      _S_one, <br />
-      _S_two <br />
-      };<br />
-<br />
-      static void <br />
-      _S_initialize_library();<br />
-      };<br />
-<br />
-      // More-or-less-standard language features described by lack, not presence.<br />
-      # ifndef _G_NO_LONGLONG<br />
-      extern long long _G_global_with_a_good_long_name;  // avoid globals!<br />
-      # endif<br />
-<br />
-      // Avoid in-class inline definitions, define separately;<br />
-      // likewise for member class definitions:<br />
-      inline int<br />
-      gribble::public_member() const<br />
-      { int __local = 0; return __local; }<br />
-<br />
-      class gribble::_Helper<br />
-      {<br />
-      int _M_stuff;<br />
-<br />
-      friend class gribble;<br />
-      };<br />
-      }<br />
-<br />
-      // Names beginning with "__": only for arguments and<br />
-      //   local variables; never use "__" in a type name, or<br />
-      //   within any name; never use "__[0-9]".<br />
-<br />
-      #endif /* _HEADER_ */<br />
-<br />
-<br />
-      namespace std <br />
-      {<br />
-      template&lt;typename T&gt;  // notice: "typename", not "class", no space<br />
-      long_return_value_type&lt;with_many, args&gt;  <br />
-      function_name(char* pointer,               // "char *pointer" is wrong.<br />
-      char* argument, <br />
-      const Reference&amp; ref)<br />
-      {<br />
-      // int a_local;  /* wrong; see below. */<br />
-      if (test) <br />
-      { <br />
-      nested code <br />
-      }<br />
-      <br />
-      int a_local = 0;  // declare variable at first use.<br />
-<br />
-      //  char a, b, *p;   /* wrong */<br />
-      char a = 'a';<br />
-      char b = a + 1;<br />
-      char* c = "abc";  // each variable goes on its own line, always.<br />
-<br />
-      // except maybe here...<br />
-      for (unsigned i = 0, mask = 1; mask; ++i, mask &lt;&lt;= 1) {<br />
-      // ...<br />
-      }<br />
-      }<br />
-      <br />
-      gribble::gribble()<br />
-      : _M_private_data(0), _M_more_stuff(0), _M_helper(0);<br />
-      { }<br />
-<br />
-      inline int <br />
-      gribble::three_lines()<br />
-      {<br />
-      // doesn't fit in one line.<br />
-      }<br />
-      } // namespace std<br />
-    </p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="source_organization.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_contributing.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="documentation_style.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Directory Layout and Source Conventions </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Documentation Style</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/source_design_notes.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/source_design_notes.html
deleted file mode 100644
index 0b3be656f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/source_design_notes.html
+++ /dev/null
@@ -1,863 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Design Notes</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_contributing.html" title="Appendix A.  Contributing" /><link rel="prev" href="documentation_style.html" title="Documentation Style" /><link rel="next" href="appendix_porting.html" title="Appendix B.  Porting and Maintenance" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Design Notes</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="documentation_style.html">Prev</a> </td><th width="60%" align="center">Appendix A. 
- Contributing
-
-</th><td width="20%" align="right"> <a accesskey="n" href="appendix_porting.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contrib.design_notes"></a>Design Notes</h2></div></div></div><p>
- </p><div class="literallayout"><p><br />
-<br />
-    The Library<br />
-    -----------<br />
-<br />
-    This paper is covers two major areas:<br />
-<br />
-    - Features and policies not mentioned in the standard that<br />
-    the quality of the library implementation depends on, including<br />
-    extensions and "implementation-defined" features;<br />
-<br />
-    - Plans for required but unimplemented library features and<br />
-    optimizations to them.<br />
-<br />
-    Overhead<br />
-    --------<br />
-<br />
-    The standard defines a large library, much larger than the standard<br />
-    C library. A naive implementation would suffer substantial overhead<br />
-    in compile time, executable size, and speed, rendering it unusable<br />
-    in many (particularly embedded) applications. The alternative demands<br />
-    care in construction, and some compiler support, but there is no<br />
-    need for library subsets.<br />
-<br />
-    What are the sources of this overhead?  There are four main causes:<br />
-<br />
-    - The library is specified almost entirely as templates, which<br />
-    with current compilers must be included in-line, resulting in<br />
-    very slow builds as tens or hundreds of thousands of lines<br />
-    of function definitions are read for each user source file.<br />
-    Indeed, the entire SGI STL, as well as the dos Reis valarray,<br />
-    are provided purely as header files, largely for simplicity in<br />
-    porting. Iostream/locale is (or will be) as large again.<br />
-<br />
-    - The library is very flexible, specifying a multitude of hooks<br />
-    where users can insert their own code in place of defaults.<br />
-    When these hooks are not used, any time and code expended to<br />
-    support that flexibility is wasted.<br />
-<br />
-    - Templates are often described as causing to "code bloat". In<br />
-    practice, this refers (when it refers to anything real) to several<br />
-    independent processes. First, when a class template is manually<br />
-    instantiated in its entirely, current compilers place the definitions<br />
-    for all members in a single object file, so that a program linking<br />
-    to one member gets definitions of all. Second, template functions<br />
-    which do not actually depend on the template argument are, under<br />
-    current compilers, generated anew for each instantiation, rather<br />
-    than being shared with other instantiations. Third, some of the<br />
-    flexibility mentioned above comes from virtual functions (both in<br />
-    regular classes and template classes) which current linkers add<br />
-    to the executable file even when they manifestly cannot be called.<br />
-<br />
-    - The library is specified to use a language feature, exceptions,<br />
-    which in the current gcc compiler ABI imposes a run time and<br />
-    code space cost to handle the possibility of exceptions even when<br />
-    they are not used. Under the new ABI (accessed with -fnew-abi),<br />
-    there is a space overhead and a small reduction in code efficiency<br />
-    resulting from lost optimization opportunities associated with<br />
-    non-local branches associated with exceptions.<br />
-<br />
-    What can be done to eliminate this overhead?  A variety of coding<br />
-    techniques, and compiler, linker and library improvements and<br />
-    extensions may be used, as covered below. Most are not difficult,<br />
-    and some are already implemented in varying degrees.<br />
-<br />
-    Overhead: Compilation Time<br />
-    --------------------------<br />
-<br />
-    Providing "ready-instantiated" template code in object code archives<br />
-    allows us to avoid generating and optimizing template instantiations<br />
-    in each compilation unit which uses them. However, the number of such<br />
-    instantiations that are useful to provide is limited, and anyway this<br />
-    is not enough, by itself, to minimize compilation time. In particular,<br />
-    it does not reduce time spent parsing conforming headers.<br />
-<br />
-    Quicker header parsing will depend on library extensions and compiler<br />
-    improvements.  One approach is some variation on the techniques<br />
-    previously marketed as "pre-compiled headers", now standardized as<br />
-    support for the "export" keyword. "Exported" template definitions<br />
-    can be placed (once) in a "repository" -- really just a library, but<br />
-    of template definitions rather than object code -- to be drawn upon<br />
-    at link time when an instantiation is needed, rather than placed in<br />
-    header files to be parsed along with every compilation unit.<br />
-<br />
-    Until "export" is implemented we can put some of the lengthy template<br />
-    definitions in #if guards or alternative headers so that users can skip<br />
-    over the full definitions when they need only the ready-instantiated<br />
-    specializations.<br />
-<br />
-    To be precise, this means that certain headers which define<br />
-    templates which users normally use only for certain arguments<br />
-    can be instrumented to avoid exposing the template definitions<br />
-    to the compiler unless a macro is defined. For example, in<br />
-    &lt;string&gt;, we might have:<br />
-<br />
-    template &lt;class _CharT, ... &gt; class basic_string {<br />
-    ... // member declarations<br />
-    };<br />
-    ... // operator declarations<br />
-<br />
-    #ifdef _STRICT_ISO_<br />
-    # if _G_NO_TEMPLATE_EXPORT<br />
-    #   include &lt;bits/std_locale.h&gt;  // headers needed by definitions<br />
-    #   ...<br />
-    #   include &lt;bits/string.tcc&gt;  // member and global template definitions.<br />
-    # endif<br />
-    #endif<br />
-<br />
-    Users who compile without specifying a strict-ISO-conforming flag<br />
-    would not see many of the template definitions they now see, and rely<br />
-    instead on ready-instantiated specializations in the library. This<br />
-    technique would be useful for the following substantial components:<br />
-    string, locale/iostreams, valarray. It would *not* be useful or<br />
-    usable with the following: containers, algorithms, iterators,<br />
-    allocator. Since these constitute a large (though decreasing)<br />
-    fraction of the library, the benefit the technique offers is<br />
-    limited.<br />
-<br />
-    The language specifies the semantics of the "export" keyword, but<br />
-    the gcc compiler does not yet support it. When it does, problems<br />
-    with large template inclusions can largely disappear, given some<br />
-    minor library reorganization, along with the need for the apparatus<br />
-    described above.<br />
-<br />
-    Overhead: Flexibility Cost<br />
-    --------------------------<br />
-<br />
-    The library offers many places where users can specify operations<br />
-    to be performed by the library in place of defaults. Sometimes<br />
-    this seems to require that the library use a more-roundabout, and<br />
-    possibly slower, way to accomplish the default requirements than<br />
-    would be used otherwise.<br />
-<br />
-    The primary protection against this overhead is thorough compiler<br />
-    optimization, to crush out layers of inline function interfaces.<br />
-    Kuck &amp; Associates has demonstrated the practicality of this kind<br />
-    of optimization.<br />
-<br />
-    The second line of defense against this overhead is explicit<br />
-    specialization. By defining helper function templates, and writing<br />
-    specialized code for the default case, overhead can be eliminated<br />
-    for that case without sacrificing flexibility. This takes full<br />
-    advantage of any ability of the optimizer to crush out degenerate<br />
-    code.<br />
-<br />
-    The library specifies many virtual functions which current linkers<br />
-    load even when they cannot be called. Some minor improvements to the<br />
-    compiler and to ld would eliminate any such overhead by simply<br />
-    omitting virtual functions that the complete program does not call.<br />
-    A prototype of this work has already been done. For targets where<br />
-    GNU ld is not used, a "pre-linker" could do the same job.<br />
-<br />
-    The main areas in the standard interface where user flexibility<br />
-    can result in overhead are:<br />
-<br />
-    - Allocators:  Containers are specified to use user-definable<br />
-    allocator types and objects, making tuning for the container<br />
-    characteristics tricky.<br />
-<br />
-    - Locales: the standard specifies locale objects used to implement<br />
-    iostream operations, involving many virtual functions which use<br />
-    streambuf iterators.<br />
-<br />
-    - Algorithms and containers: these may be instantiated on any type,<br />
-    frequently duplicating code for identical operations.<br />
-<br />
-    - Iostreams and strings: users are permitted to use these on their<br />
-    own types, and specify the operations the stream must use on these<br />
-    types.<br />
-<br />
-    Note that these sources of overhead are _avoidable_. The techniques<br />
-    to avoid them are covered below.<br />
-<br />
-    Code Bloat<br />
-    ----------<br />
-<br />
-    In the SGI STL, and in some other headers, many of the templates<br />
-    are defined "inline" -- either explicitly or by their placement<br />
-    in class definitions -- which should not be inline. This is a<br />
-    source of code bloat. Matt had remarked that he was relying on<br />
-    the compiler to recognize what was too big to benefit from inlining,<br />
-    and generate it out-of-line automatically. However, this also can<br />
-    result in code bloat except where the linker can eliminate the extra<br />
-    copies.<br />
-<br />
-    Fixing these cases will require an audit of all inline functions<br />
-    defined in the library to determine which merit inlining, and moving<br />
-    the rest out of line. This is an issue mainly in chapters 23, 25, and<br />
-    27. Of course it can be done incrementally, and we should generally<br />
-    accept patches that move large functions out of line and into ".tcc"<br />
-    files, which can later be pulled into a repository. Compiler/linker<br />
-    improvements to recognize very large inline functions and move them<br />
-    out-of-line, but shared among compilation units, could make this<br />
-    work unnecessary.<br />
-<br />
-    Pre-instantiating template specializations currently produces large<br />
-    amounts of dead code which bloats statically linked programs. The<br />
-    current state of the static library, libstdc++.a, is intolerable on<br />
-    this account, and will fuel further confused speculation about a need<br />
-    for a library "subset". A compiler improvement that treats each<br />
-    instantiated function as a separate object file, for linking purposes,<br />
-    would be one solution to this problem. An alternative would be to<br />
-    split up the manual instantiation files into dozens upon dozens of<br />
-    little files, each compiled separately, but an abortive attempt at<br />
-    this was done for &lt;string&gt; and, though it is far from complete, it<br />
-    is already a nuisance. A better interim solution (just until we have<br />
-    "export") is badly needed.<br />
-<br />
-    When building a shared library, the current compiler/linker cannot<br />
-    automatically generate the instantiations needed. This creates a<br />
-    miserable situation; it means any time something is changed in the<br />
-    library, before a shared library can be built someone must manually<br />
-    copy the declarations of all templates that are needed by other parts<br />
-    of the library to an "instantiation" file, and add it to the build<br />
-    system to be compiled and linked to the library. This process is<br />
-    readily automated, and should be automated as soon as possible.<br />
-    Users building their own shared libraries experience identical<br />
-    frustrations.<br />
-<br />
-    Sharing common aspects of template definitions among instantiations<br />
-    can radically reduce code bloat. The compiler could help a great<br />
-    deal here by recognizing when a function depends on nothing about<br />
-    a template parameter, or only on its size, and giving the resulting<br />
-    function a link-name "equate" that allows it to be shared with other<br />
-    instantiations. Implementation code could take advantage of the<br />
-    capability by factoring out code that does not depend on the template<br />
-    argument into separate functions to be merged by the compiler.<br />
-<br />
-    Until such a compiler optimization is implemented, much can be done<br />
-    manually (if tediously) in this direction. One such optimization is<br />
-    to derive class templates from non-template classes, and move as much<br />
-    implementation as possible into the base class. Another is to partial-<br />
-    specialize certain common instantiations, such as vector&lt;T*&gt;, to share<br />
-    code for instantiations on all types T. While these techniques work,<br />
-    they are far from the complete solution that a compiler improvement<br />
-    would afford.<br />
-<br />
-    Overhead: Expensive Language Features<br />
-    -------------------------------------<br />
-<br />
-    The main "expensive" language feature used in the standard library<br />
-    is exception support, which requires compiling in cleanup code with<br />
-    static table data to locate it, and linking in library code to use<br />
-    the table. For small embedded programs the amount of such library<br />
-    code and table data is assumed by some to be excessive. Under the<br />
-    "new" ABI this perception is generally exaggerated, although in some<br />
-    cases it may actually be excessive.<br />
-<br />
-    To implement a library which does not use exceptions directly is<br />
-    not difficult given minor compiler support (to "turn off" exceptions<br />
-    and ignore exception constructs), and results in no great library<br />
-    maintenance difficulties. To be precise, given "-fno-exceptions",<br />
-    the compiler should treat "try" blocks as ordinary blocks, and<br />
-    "catch" blocks as dead code to ignore or eliminate. Compiler<br />
-    support is not strictly necessary, except in the case of "function<br />
-    try blocks"; otherwise the following macros almost suffice:<br />
-<br />
-    #define throw(X)<br />
-    #define try      if (true)<br />
-    #define catch(X) else if (false)<br />
-<br />
-    However, there may be a need to use function try blocks in the<br />
-    library implementation, and use of macros in this way can make<br />
-    correct diagnostics impossible. Furthermore, use of this scheme<br />
-    would require the library to call a function to re-throw exceptions<br />
-    from a try block. Implementing the above semantics in the compiler<br />
-    is preferable.<br />
-<br />
-    Given the support above (however implemented) it only remains to<br />
-    replace code that "throws" with a call to a well-documented "handler"<br />
-    function in a separate compilation unit which may be replaced by<br />
-    the user. The main source of exceptions that would be difficult<br />
-    for users to avoid is memory allocation failures, but users can<br />
-    define their own memory allocation primitives that never throw.<br />
-    Otherwise, the complete list of such handlers, and which library<br />
-    functions may call them, would be needed for users to be able to<br />
-    implement the necessary substitutes. (Fortunately, they have the<br />
-    source code.)<br />
-<br />
-    Opportunities<br />
-    -------------<br />
-<br />
-    The template capabilities of C++ offer enormous opportunities for<br />
-    optimizing common library operations, well beyond what would be<br />
-    considered "eliminating overhead". In particular, many operations<br />
-    done in Glibc with macros that depend on proprietary language<br />
-    extensions can be implemented in pristine Standard C++. For example,<br />
-    the chapter 25 algorithms, and even C library functions such as strchr,<br />
-    can be specialized for the case of static arrays of known (small) size.<br />
-<br />
-    Detailed optimization opportunities are identified below where<br />
-    the component where they would appear is discussed. Of course new<br />
-    opportunities will be identified during implementation.<br />
-<br />
-    Unimplemented Required Library Features<br />
-    ---------------------------------------<br />
-<br />
-    The standard specifies hundreds of components, grouped broadly by<br />
-    chapter. These are listed in excruciating detail in the CHECKLIST<br />
-    file.<br />
-<br />
-    17 general<br />
-    18 support<br />
-    19 diagnostics<br />
-    20 utilities<br />
-    21 string<br />
-    22 locale<br />
-    23 containers<br />
-    24 iterators<br />
-    25 algorithms<br />
-    26 numerics<br />
-    27 iostreams<br />
-    Annex D  backward compatibility<br />
-<br />
-    Anyone participating in implementation of the library should obtain<br />
-    a copy of the standard, ISO 14882.  People in the U.S. can obtain an<br />
-    electronic copy for US$18 from ANSI's web site. Those from other<br />
-    countries should visit http://www.iso.ch/ to find out the location<br />
-    of their country's representation in ISO, in order to know who can<br />
-    sell them a copy.<br />
-<br />
-    The emphasis in the following sections is on unimplemented features<br />
-    and optimization opportunities.<br />
-<br />
-    Chapter 17  General<br />
-    -------------------<br />
-<br />
-    Chapter 17 concerns overall library requirements.<br />
-<br />
-    The standard doesn't mention threads. A multi-thread (MT) extension<br />
-    primarily affects operators new and delete (18), allocator (20),<br />
-    string (21), locale (22), and iostreams (27). The common underlying<br />
-    support needed for this is discussed under chapter 20.<br />
-<br />
-    The standard requirements on names from the C headers create a<br />
-    lot of work, mostly done. Names in the C headers must be visible<br />
-    in the std:: and sometimes the global namespace; the names in the<br />
-    two scopes must refer to the same object. More stringent is that<br />
-    Koenig lookup implies that any types specified as defined in std::<br />
-    really are defined in std::. Names optionally implemented as<br />
-    macros in C cannot be macros in C++. (An overview may be read at<br />
-    &lt;http://www.cantrip.org/cheaders.html&gt;). The scripts "inclosure"<br />
-    and "mkcshadow", and the directories shadow/ and cshadow/, are the<br />
-    beginning of an effort to conform in this area.<br />
-<br />
-    A correct conforming definition of C header names based on underlying<br />
-    C library headers, and practical linking of conforming namespaced<br />
-    customer code with third-party C libraries depends ultimately on<br />
-    an ABI change, allowing namespaced C type names to be mangled into<br />
-    type names as if they were global, somewhat as C function names in a<br />
-    namespace, or C++ global variable names, are left unmangled. Perhaps<br />
-    another "extern" mode, such as 'extern "C-global"' would be an<br />
-    appropriate place for such type definitions. Such a type would<br />
-    affect mangling as follows:<br />
-<br />
-    namespace A {<br />
-    struct X {};<br />
-    extern "C-global" {  // or maybe just 'extern "C"'<br />
-    struct Y {};<br />
-    };<br />
-    }<br />
-    void f(A::X*);  // mangles to f__FPQ21A1X<br />
-    void f(A::Y*);  // mangles to f__FP1Y<br />
-<br />
-    (It may be that this is really the appropriate semantics for regular<br />
-    'extern "C"', and 'extern "C-global"', as an extension, would not be<br />
-    necessary.) This would allow functions declared in non-standard C headers<br />
-    (and thus fixable by neither us nor users) to link properly with functions<br />
-    declared using C types defined in properly-namespaced headers. The<br />
-    problem this solves is that C headers (which C++ programmers do persist<br />
-    in using) frequently forward-declare C struct tags without including<br />
-    the header where the type is defined, as in<br />
-<br />
-    struct tm;<br />
-    void munge(tm*);<br />
-<br />
-    Without some compiler accommodation, munge cannot be called by correct<br />
-    C++ code using a pointer to a correctly-scoped tm* value.<br />
-<br />
-    The current C headers use the preprocessor extension "#include_next",<br />
-    which the compiler complains about when run "-pedantic".<br />
-    (Incidentally, it appears that "-fpedantic" is currently ignored,<br />
-    probably a bug.)  The solution in the C compiler is to use<br />
-    "-isystem" rather than "-I", but unfortunately in g++ this seems<br />
-    also to wrap the whole header in an 'extern "C"' block, so it's<br />
-    unusable for C++ headers. The correct solution appears to be to<br />
-    allow the various special include-directory options, if not given<br />
-    an argument, to affect subsequent include-directory options additively,<br />
-    so that if one said<br />
-<br />
-    -pedantic -iprefix $(prefix) \<br />
-    -idirafter -ino-pedantic -ino-extern-c -iwithprefix -I g++-v3 \<br />
-    -iwithprefix -I g++-v3/ext<br />
-<br />
-    the compiler would search $(prefix)/g++-v3 and not report<br />
-    pedantic warnings for files found there, but treat files in<br />
-    $(prefix)/g++-v3/ext pedantically. (The undocumented semantics<br />
-    of "-isystem" in g++ stink. Can they be rescinded?  If not it<br />
-    must be replaced with something more rationally behaved.)<br />
-<br />
-    All the C headers need the treatment above; in the standard these<br />
-    headers are mentioned in various chapters. Below, I have only<br />
-    mentioned those that present interesting implementation issues.<br />
-<br />
-    The components identified as "mostly complete", below, have not been<br />
-    audited for conformance. In many cases where the library passes<br />
-    conformance tests we have non-conforming extensions that must be<br />
-    wrapped in #if guards for "pedantic" use, and in some cases renamed<br />
-    in a conforming way for continued use in the implementation regardless<br />
-    of conformance flags.<br />
-<br />
-    The STL portion of the library still depends on a header<br />
-    stl/bits/stl_config.h full of #ifdef clauses. This apparatus<br />
-    should be replaced with autoconf/automake machinery.<br />
-<br />
-    The SGI STL defines a type_traits&lt;&gt; template, specialized for<br />
-    many types in their code including the built-in numeric and<br />
-    pointer types and some library types, to direct optimizations of<br />
-    standard functions. The SGI compiler has been extended to generate<br />
-    specializations of this template automatically for user types,<br />
-    so that use of STL templates on user types can take advantage of<br />
-    these optimizations. Specializations for other, non-STL, types<br />
-    would make more optimizations possible, but extending the gcc<br />
-    compiler in the same way would be much better. Probably the next<br />
-    round of standardization will ratify this, but probably with<br />
-    changes, so it probably should be renamed to place it in the<br />
-    implementation namespace.<br />
-<br />
-    The SGI STL also defines a large number of extensions visible in<br />
-    standard headers. (Other extensions that appear in separate headers<br />
-    have been sequestered in subdirectories ext/ and backward/.)  All<br />
-    these extensions should be moved to other headers where possible,<br />
-    and in any case wrapped in a namespace (not std!), and (where kept<br />
-    in a standard header) girded about with macro guards. Some cannot be<br />
-    moved out of standard headers because they are used to implement<br />
-    standard features.  The canonical method for accommodating these<br />
-    is to use a protected name, aliased in macro guards to a user-space<br />
-    name. Unfortunately C++ offers no satisfactory template typedef<br />
-    mechanism, so very ad-hoc and unsatisfactory aliasing must be used<br />
-    instead.<br />
-<br />
-    Implementation of a template typedef mechanism should have the highest<br />
-    priority among possible extensions, on the same level as implementation<br />
-    of the template "export" feature.<br />
-<br />
-    Chapter 18  Language support<br />
-    ----------------------------<br />
-<br />
-    Headers: &lt;limits&gt; &lt;new&gt; &lt;typeinfo&gt; &lt;exception&gt;<br />
-    C headers: &lt;cstddef&gt; &lt;climits&gt; &lt;cfloat&gt;  &lt;cstdarg&gt; &lt;csetjmp&gt;<br />
-    &lt;ctime&gt;   &lt;csignal&gt; &lt;cstdlib&gt; (also 21, 25, 26)<br />
-<br />
-    This defines the built-in exceptions, rtti, numeric_limits&lt;&gt;,<br />
-    operator new and delete. Much of this is provided by the<br />
-    compiler in its static runtime library.<br />
-<br />
-    Work to do includes defining numeric_limits&lt;&gt; specializations in<br />
-    separate files for all target architectures. Values for integer types<br />
-    except for bool and wchar_t are readily obtained from the C header<br />
-    &lt;limits.h&gt;, but values for the remaining numeric types (bool, wchar_t,<br />
-    float, double, long double) must be entered manually. This is<br />
-    largely dog work except for those members whose values are not<br />
-    easily deduced from available documentation. Also, this involves<br />
-    some work in target configuration to identify the correct choice of<br />
-    file to build against and to install.<br />
-<br />
-    The definitions of the various operators new and delete must be<br />
-    made thread-safe, which depends on a portable exclusion mechanism,<br />
-    discussed under chapter 20.  Of course there is always plenty of<br />
-    room for improvements to the speed of operators new and delete.<br />
-<br />
-    &lt;cstdarg&gt;, in Glibc, defines some macros that gcc does not allow to<br />
-    be wrapped into an inline function. Probably this header will demand<br />
-    attention whenever a new target is chosen. The functions atexit(),<br />
-    exit(), and abort() in cstdlib have different semantics in C++, so<br />
-    must be re-implemented for C++.<br />
-<br />
-    Chapter 19  Diagnostics<br />
-    -----------------------<br />
-<br />
-    Headers: &lt;stdexcept&gt;<br />
-    C headers: &lt;cassert&gt; &lt;cerrno&gt;<br />
-<br />
-    This defines the standard exception objects, which are "mostly complete".<br />
-    Cygnus has a version, and now SGI provides a slightly different one.<br />
-    It makes little difference which we use.<br />
-<br />
-    The C global name "errno", which C allows to be a variable or a macro,<br />
-    is required in C++ to be a macro. For MT it must typically result in<br />
-    a function call.<br />
-<br />
-    Chapter 20  Utilities<br />
-    ---------------------<br />
-    Headers: &lt;utility&gt; &lt;functional&gt; &lt;memory&gt;<br />
-    C header: &lt;ctime&gt; (also in 18)<br />
-<br />
-    SGI STL provides "mostly complete" versions of all the components<br />
-    defined in this chapter. However, the auto_ptr&lt;&gt; implementation<br />
-    is known to be wrong. Furthermore, the standard definition of it<br />
-    is known to be unimplementable as written. A minor change to the<br />
-    standard would fix it, and auto_ptr&lt;&gt; should be adjusted to match.<br />
-<br />
-    Multi-threading affects the allocator implementation, and there must<br />
-    be configuration/installation choices for different users' MT<br />
-    requirements. Anyway, users will want to tune allocator options<br />
-    to support different target conditions, MT or no.<br />
-<br />
-    The primitives used for MT implementation should be exposed, as an<br />
-    extension, for users' own work. We need cross-CPU "mutex" support,<br />
-    multi-processor shared-memory atomic integer operations, and single-<br />
-    processor uninterruptible integer operations, and all three configurable<br />
-    to be stubbed out for non-MT use, or to use an appropriately-loaded<br />
-    dynamic library for the actual runtime environment, or statically<br />
-    compiled in for cases where the target architecture is known.<br />
-<br />
-    Chapter 21  String<br />
-    ------------------<br />
-    Headers: &lt;string&gt;<br />
-    C headers: &lt;cctype&gt; &lt;cwctype&gt; &lt;cstring&gt; &lt;cwchar&gt; (also in 27)<br />
-    &lt;cstdlib&gt; (also in 18, 25, 26)<br />
-<br />
-    We have "mostly-complete" char_traits&lt;&gt; implementations. Many of the<br />
-    char_traits&lt;char&gt; operations might be optimized further using existing<br />
-    proprietary language extensions.<br />
-<br />
-    We have a "mostly-complete" basic_string&lt;&gt; implementation. The work<br />
-    to manually instantiate char and wchar_t specializations in object<br />
-    files to improve link-time behavior is extremely unsatisfactory,<br />
-    literally tripling library-build time with no commensurate improvement<br />
-    in static program link sizes. It must be redone. (Similar work is<br />
-    needed for some components in chapters 22 and 27.)<br />
-<br />
-    Other work needed for strings is MT-safety, as discussed under the<br />
-    chapter 20 heading.<br />
-<br />
-    The standard C type mbstate_t from &lt;cwchar&gt; and used in char_traits&lt;&gt;<br />
-    must be different in C++ than in C, because in C++ the default constructor<br />
-    value mbstate_t() must be the "base" or "ground" sequence state.<br />
-    (According to the likely resolution of a recently raised Core issue,<br />
-    this may become unnecessary. However, there are other reasons to<br />
-    use a state type not as limited as whatever the C library provides.)<br />
-    If we might want to provide conversions from (e.g.) internally-<br />
-    represented EUC-wide to externally-represented Unicode, or vice-<br />
-    versa, the mbstate_t we choose will need to be more accommodating<br />
-    than what might be provided by an underlying C library.<br />
-<br />
-    There remain some basic_string template-member functions which do<br />
-    not overload properly with their non-template brethren. The infamous<br />
-    hack akin to what was done in vector&lt;&gt; is needed, to conform to<br />
-    23.1.1 para 10. The CHECKLIST items for basic_string marked 'X',<br />
-    or incomplete, are so marked for this reason.<br />
-<br />
-    Replacing the string iterators, which currently are simple character<br />
-    pointers, with class objects would greatly increase the safety of the<br />
-    client interface, and also permit a "debug" mode in which range,<br />
-    ownership, and validity are rigorously checked. The current use of<br />
-    raw pointers as string iterators is evil. vector&lt;&gt; iterators need the<br />
-    same treatment. Note that the current implementation freely mixes<br />
-    pointers and iterators, and that must be fixed before safer iterators<br />
-    can be introduced.<br />
-<br />
-    Some of the functions in &lt;cstring&gt; are different from the C version.<br />
-    generally overloaded on const and non-const argument pointers. For<br />
-    example, in &lt;cstring&gt; strchr is overloaded. The functions isupper<br />
-    etc. in &lt;cctype&gt; typically implemented as macros in C are functions<br />
-    in C++, because they are overloaded with others of the same name<br />
-    defined in &lt;locale&gt;.<br />
-<br />
-    Many of the functions required in &lt;cwctype&gt; and &lt;cwchar&gt; cannot be<br />
-    implemented using underlying C facilities on intended targets because<br />
-    such facilities only partly exist.<br />
-<br />
-    Chapter 22  Locale<br />
-    ------------------<br />
-    Headers: &lt;locale&gt;<br />
-    C headers: &lt;clocale&gt;<br />
-<br />
-    We have a "mostly complete" class locale, with the exception of<br />
-    code for constructing, and handling the names of, named locales.<br />
-    The ways that locales are named (particularly when categories<br />
-    (e.g. LC_TIME, LC_COLLATE) are different) varies among all target<br />
-    environments. This code must be written in various versions and<br />
-    chosen by configuration parameters.<br />
-<br />
-    Members of many of the facets defined in &lt;locale&gt; are stubs. Generally,<br />
-    there are two sets of facets: the base class facets (which are supposed<br />
-    to implement the "C" locale) and the "byname" facets, which are supposed<br />
-    to read files to determine their behavior. The base ctype&lt;&gt;, collate&lt;&gt;,<br />
-    and numpunct&lt;&gt; facets are "mostly complete", except that the table of<br />
-    bitmask values used for "is" operations, and corresponding mask values,<br />
-    are still defined in libio and just included/linked. (We will need to<br />
-    implement these tables independently, soon, but should take advantage<br />
-    of libio where possible.)  The num_put&lt;&gt;::put members for integer types<br />
-    are "mostly complete".<br />
-<br />
-    A complete list of what has and has not been implemented may be<br />
-    found in CHECKLIST. However, note that the current definition of<br />
-    codecvt&lt;wchar_t,char,mbstate_t&gt; is wrong. It should simply write<br />
-    out the raw bytes representing the wide characters, rather than<br />
-    trying to convert each to a corresponding single "char" value.<br />
-<br />
-    Some of the facets are more important than others. Specifically,<br />
-    the members of ctype&lt;&gt;, numpunct&lt;&gt;, num_put&lt;&gt;, and num_get&lt;&gt; facets<br />
-    are used by other library facilities defined in &lt;string&gt;, &lt;istream&gt;,<br />
-    and &lt;ostream&gt;, and the codecvt&lt;&gt; facet is used by basic_filebuf&lt;&gt;<br />
-    in &lt;fstream&gt;, so a conforming iostream implementation depends on<br />
-    these.<br />
-<br />
-    The "long long" type eventually must be supported, but code mentioning<br />
-    it should be wrapped in #if guards to allow pedantic-mode compiling.<br />
-<br />
-    Performance of num_put&lt;&gt; and num_get&lt;&gt; depend critically on<br />
-    caching computed values in ios_base objects, and on extensions<br />
-    to the interface with streambufs.<br />
-<br />
-    Specifically: retrieving a copy of the locale object, extracting<br />
-    the needed facets, and gathering data from them, for each call to<br />
-    (e.g.) operator&lt;&lt; would be prohibitively slow.  To cache format<br />
-    data for use by num_put&lt;&gt; and num_get&lt;&gt; we have a _Format_cache&lt;&gt;<br />
-    object stored in the ios_base::pword() array. This is constructed<br />
-    and initialized lazily, and is organized purely for utility. It<br />
-    is discarded when a new locale with different facets is imbued.<br />
-<br />
-    Using only the public interfaces of the iterator arguments to the<br />
-    facet functions would limit performance by forbidding "vector-style"<br />
-    character operations. The streambuf iterator optimizations are<br />
-    described under chapter 24, but facets can also bypass the streambuf<br />
-    iterators via explicit specializations and operate directly on the<br />
-    streambufs, and use extended interfaces to get direct access to the<br />
-    streambuf internal buffer arrays. These extensions are mentioned<br />
-    under chapter 27. These optimizations are particularly important<br />
-    for input parsing.<br />
-<br />
-    Unused virtual members of locale facets can be omitted, as mentioned<br />
-    above, by a smart linker.<br />
-<br />
-    Chapter 23  Containers<br />
-    ----------------------<br />
-    Headers: &lt;deque&gt; &lt;list&gt; &lt;queue&gt; &lt;stack&gt; &lt;vector&gt; &lt;map&gt; &lt;set&gt; &lt;bitset&gt;<br />
-<br />
-    All the components in chapter 23 are implemented in the SGI STL.<br />
-    They are "mostly complete"; they include a large number of<br />
-    nonconforming extensions which must be wrapped. Some of these<br />
-    are used internally and must be renamed or duplicated.<br />
-<br />
-    The SGI components are optimized for large-memory environments. For<br />
-    embedded targets, different criteria might be more appropriate. Users<br />
-    will want to be able to tune this behavior. We should provide<br />
-    ways for users to compile the library with different memory usage<br />
-    characteristics.<br />
-<br />
-    A lot more work is needed on factoring out common code from different<br />
-    specializations to reduce code size here and in chapter 25. The<br />
-    easiest fix for this would be a compiler/ABI improvement that allows<br />
-    the compiler to recognize when a specialization depends only on the<br />
-    size (or other gross quality) of a template argument, and allow the<br />
-    linker to share the code with similar specializations. In its<br />
-    absence, many of the algorithms and containers can be partial-<br />
-    specialized, at least for the case of pointers, but this only solves<br />
-    a small part of the problem. Use of a type_traits-style template<br />
-    allows a few more optimization opportunities, more if the compiler<br />
-    can generate the specializations automatically.<br />
-<br />
-    As an optimization, containers can specialize on the default allocator<br />
-    and bypass it, or take advantage of details of its implementation<br />
-    after it has been improved upon.<br />
-<br />
-    Replacing the vector iterators, which currently are simple element<br />
-    pointers, with class objects would greatly increase the safety of the<br />
-    client interface, and also permit a "debug" mode in which range,<br />
-    ownership, and validity are rigorously checked. The current use of<br />
-    pointers for iterators is evil.<br />
-<br />
-    As mentioned for chapter 24, the deque iterator is a good example of<br />
-    an opportunity to implement a "staged" iterator that would benefit<br />
-    from specializations of some algorithms.<br />
-<br />
-    Chapter 24  Iterators<br />
-    ---------------------<br />
-    Headers: &lt;iterator&gt;<br />
-<br />
-    Standard iterators are "mostly complete", with the exception of<br />
-    the stream iterators, which are not yet templatized on the<br />
-    stream type. Also, the base class template iterator&lt;&gt; appears<br />
-    to be wrong, so everything derived from it must also be wrong,<br />
-    currently.<br />
-<br />
-    The streambuf iterators (currently located in stl/bits/std_iterator.h,<br />
-    but should be under bits/) can be rewritten to take advantage of<br />
-    friendship with the streambuf implementation.<br />
-<br />
-    Matt Austern has identified opportunities where certain iterator<br />
-    types, particularly including streambuf iterators and deque<br />
-    iterators, have a "two-stage" quality, such that an intermediate<br />
-    limit can be checked much more quickly than the true limit on<br />
-    range operations. If identified with a member of iterator_traits,<br />
-    algorithms may be specialized for this case. Of course the<br />
-    iterators that have this quality can be identified by specializing<br />
-    a traits class.<br />
-<br />
-    Many of the algorithms must be specialized for the streambuf<br />
-    iterators, to take advantage of block-mode operations, in order<br />
-    to allow iostream/locale operations' performance not to suffer.<br />
-    It may be that they could be treated as staged iterators and<br />
-    take advantage of those optimizations.<br />
-<br />
-    Chapter 25  Algorithms<br />
-    ----------------------<br />
-    Headers: &lt;algorithm&gt;<br />
-    C headers: &lt;cstdlib&gt; (also in 18, 21, 26))<br />
-<br />
-    The algorithms are "mostly complete". As mentioned above, they<br />
-    are optimized for speed at the expense of code and data size.<br />
-<br />
-    Specializations of many of the algorithms for non-STL types would<br />
-    give performance improvements, but we must use great care not to<br />
-    interfere with fragile template overloading semantics for the<br />
-    standard interfaces. Conventionally the standard function template<br />
-    interface is an inline which delegates to a non-standard function<br />
-    which is then overloaded (this is already done in many places in<br />
-    the library). Particularly appealing opportunities for the sake of<br />
-    iostream performance are for copy and find applied to streambuf<br />
-    iterators or (as noted elsewhere) for staged iterators, of which<br />
-    the streambuf iterators are a good example.<br />
-<br />
-    The bsearch and qsort functions cannot be overloaded properly as<br />
-    required by the standard because gcc does not yet allow overloading<br />
-    on the extern-"C"-ness of a function pointer.<br />
-<br />
-    Chapter 26  Numerics<br />
-    --------------------<br />
-    Headers: &lt;complex&gt; &lt;valarray&gt; &lt;numeric&gt;<br />
-    C headers: &lt;cmath&gt;, &lt;cstdlib&gt; (also 18, 21, 25)<br />
-<br />
-    Numeric components: Gabriel dos Reis's valarray, Drepper's complex,<br />
-    and the few algorithms from the STL are "mostly done".  Of course<br />
-    optimization opportunities abound for the numerically literate. It<br />
-    is not clear whether the valarray implementation really conforms<br />
-    fully, in the assumptions it makes about aliasing (and lack thereof)<br />
-    in its arguments.<br />
-<br />
-    The C div() and ldiv() functions are interesting, because they are the<br />
-    only case where a C library function returns a class object by value.<br />
-    Since the C++ type div_t must be different from the underlying C type<br />
-    (which is in the wrong namespace) the underlying functions div() and<br />
-    ldiv() cannot be re-used efficiently. Fortunately they are trivial to<br />
-    re-implement.<br />
-<br />
-    Chapter 27  Iostreams<br />
-    ---------------------<br />
-    Headers: &lt;iosfwd&gt; &lt;streambuf&gt; &lt;ios&gt; &lt;ostream&gt; &lt;istream&gt; &lt;iostream&gt;<br />
-    &lt;iomanip&gt; &lt;sstream&gt; &lt;fstream&gt;<br />
-    C headers: &lt;cstdio&gt; &lt;cwchar&gt; (also in 21)<br />
-<br />
-    Iostream is currently in a very incomplete state. &lt;iosfwd&gt;, &lt;iomanip&gt;,<br />
-    ios_base, and basic_ios&lt;&gt; are "mostly complete". basic_streambuf&lt;&gt; and<br />
-    basic_ostream&lt;&gt; are well along, but basic_istream&lt;&gt; has had little work<br />
-    done. The standard stream objects, &lt;sstream&gt; and &lt;fstream&gt; have been<br />
-    started; basic_filebuf&lt;&gt; "write" functions have been implemented just<br />
-    enough to do "hello, world".<br />
-<br />
-    Most of the istream and ostream operators &lt;&lt; and &gt;&gt; (with the exception<br />
-    of the op&lt;&lt;(integer) ones) have not been changed to use locale primitives,<br />
-    sentry objects, or char_traits members.<br />
-<br />
-    All these templates should be manually instantiated for char and<br />
-    wchar_t in a way that links only used members into user programs.<br />
-<br />
-    Streambuf is fertile ground for optimization extensions. An extended<br />
-    interface giving iterator access to its internal buffer would be very<br />
-    useful for other library components.<br />
-<br />
-    Iostream operations (primarily operators &lt;&lt; and &gt;&gt;) can take advantage<br />
-    of the case where user code has not specified a locale, and bypass locale<br />
-    operations entirely. The current implementation of op&lt;&lt;/num_put&lt;&gt;::put,<br />
-    for the integer types, demonstrates how they can cache encoding details<br />
-    from the locale on each operation. There is lots more room for<br />
-    optimization in this area.<br />
-<br />
-    The definition of the relationship between the standard streams<br />
-    cout et al. and stdout et al. requires something like a "stdiobuf".<br />
-    The SGI solution of using double-indirection to actually use a<br />
-    stdio FILE object for buffering is unsatisfactory, because it<br />
-    interferes with peephole loop optimizations.<br />
-<br />
-    The &lt;sstream&gt; header work has begun. stringbuf can benefit from<br />
-    friendship with basic_string&lt;&gt; and basic_string&lt;&gt;::_Rep to use<br />
-    those objects directly as buffers, and avoid allocating and making<br />
-    copies.<br />
-<br />
-    The basic_filebuf&lt;&gt; template is a complex beast. It is specified to<br />
-    use the locale facet codecvt&lt;&gt; to translate characters between native<br />
-    files and the locale character encoding. In general this involves<br />
-    two buffers, one of "char" representing the file and another of<br />
-    "char_type", for the stream, with codecvt&lt;&gt; translating. The process<br />
-    is complicated by the variable-length nature of the translation, and<br />
-    the need to seek to corresponding places in the two representations.<br />
-    For the case of basic_filebuf&lt;char&gt;, when no translation is needed,<br />
-    a single buffer suffices. A specialized filebuf can be used to reduce<br />
-    code space overhead when no locale has been imbued. Matt Austern's<br />
-    work at SGI will be useful, perhaps directly as a source of code, or<br />
-    at least as an example to draw on.<br />
-<br />
-    Filebuf, almost uniquely (cf. operator new), depends heavily on<br />
-    underlying environmental facilities. In current releases iostream<br />
-    depends fairly heavily on libio constant definitions, but it should<br />
-    be made independent.  It also depends on operating system primitives<br />
-    for file operations. There is immense room for optimizations using<br />
-    (e.g.) mmap for reading. The shadow/ directory wraps, besides the<br />
-    standard C headers, the libio.h and unistd.h headers, for use mainly<br />
-    by filebuf. These wrappings have not been completed, though there<br />
-    is scaffolding in place.<br />
-<br />
-    The encapsulation of certain C header &lt;cstdio&gt; names presents an<br />
-    interesting problem. It is possible to define an inline std::fprintf()<br />
-    implemented in terms of the 'extern "C"' vfprintf(), but there is no<br />
-    standard vfscanf() to use to implement std::fscanf(). It appears that<br />
-    vfscanf but be re-implemented in C++ for targets where no vfscanf<br />
-    extension has been defined. This is interesting in that it seems<br />
-    to be the only significant case in the C library where this kind of<br />
-    rewriting is necessary. (Of course Glibc provides the vfscanf()<br />
-    extension.)  (The functions related to exit() must be rewritten<br />
-    for other reasons.)<br />
-<br />
-<br />
-    Annex D<br />
-    -------<br />
-    Headers: &lt;strstream&gt;<br />
-<br />
-    Annex D defines many non-library features, and many minor<br />
-    modifications to various headers, and a complete header.<br />
-    It is "mostly done", except that the libstdc++-2 &lt;strstream&gt;<br />
-    header has not been adopted into the library, or checked to<br />
-    verify that it matches the draft in those details that were<br />
-    clarified by the committee. Certainly it must at least be<br />
-    moved into the std namespace.<br />
-<br />
-    We still need to wrap all the deprecated features in #if guards<br />
-    so that pedantic compile modes can detect their use.<br />
-<br />
-    Nonstandard Extensions<br />
-    ----------------------<br />
-    Headers: &lt;iostream.h&gt; &lt;strstream.h&gt; &lt;hash&gt; &lt;rbtree&gt;<br />
-    &lt;pthread_alloc&gt; &lt;stdiobuf&gt; (etc.)<br />
-<br />
-    User code has come to depend on a variety of nonstandard components<br />
-    that we must not omit. Much of this code can be adopted from<br />
-    libstdc++-v2 or from the SGI STL. This particularly includes<br />
-    &lt;iostream.h&gt;, &lt;strstream.h&gt;, and various SGI extensions such<br />
-    as &lt;hash_map.h&gt;. Many of these are already placed in the<br />
-    subdirectories ext/ and backward/. (Note that it is better to<br />
-    include them via "&lt;backward/hash_map.h&gt;" or "&lt;ext/hash_map&gt;" than<br />
-    to search the subdirectory itself via a "-I" directive.<br />
-  </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="documentation_style.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_contributing.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="appendix_porting.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Documentation Style </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix B. 
- Porting and Maintenance
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/source_organization.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/source_organization.html
deleted file mode 100644
index 54d014fbd..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/source_organization.html
+++ /dev/null
@@ -1,97 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Directory Layout and Source Conventions</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_contributing.html" title="Appendix A.  Contributing" /><link rel="prev" href="appendix_contributing.html" title="Appendix A.  Contributing" /><link rel="next" href="source_code_style.html" title="Coding Style" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Directory Layout and Source Conventions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="appendix_contributing.html">Prev</a> </td><th width="60%" align="center">Appendix A. 
- Contributing
-
-</th><td width="20%" align="right"> <a accesskey="n" href="source_code_style.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contrib.organization"></a>Directory Layout and Source Conventions</h2></div></div></div><p>
- The unpacked source directory of libstdc++ contains the files
- needed to create the GNU C++ Library.
- </p><div class="literallayout"><p><br />
-It has subdirectories:<br />
-<br />
-  doc<br />
-    Files in HTML and text format that document usage, quirks of the<br />
-    implementation, and contributor checklists.<br />
-<br />
-  include<br />
-    All header files for the C++ library are within this directory,<br />
-    modulo specific runtime-related files that are in the libsupc++<br />
-    directory.<br />
-<br />
-    include/std<br />
-      Files meant to be found by #include &lt;name&gt; directives in<br />
-      standard-conforming user programs.  <br />
-<br />
-    include/c<br />
-      Headers intended to directly include standard C headers. <br />
-      [NB: this can be enabled via --enable-cheaders=c]<br />
-<br />
-    include/c_global <br />
-      Headers intended to include standard C headers in<br />
-      the global namespace, and put select names into the std::<br />
-      namespace.  [NB: this is the default, and is the same as<br />
-      --enable-cheaders=c_global]<br />
-<br />
-    include/c_std <br />
-      Headers intended to include standard C headers<br />
-      already in namespace std, and put select names into the std::<br />
-      namespace.  [NB: this is the same as --enable-cheaders=c_std]<br />
-<br />
-    include/bits<br />
-      Files included by standard headers and by other files in<br />
-      the bits directory. <br />
-<br />
-    include/backward<br />
-      Headers provided for backward compatibility, such as &lt;iostream.h&gt;.<br />
-      They are not used in this library.<br />
-<br />
-    include/ext<br />
-      Headers that define extensions to the standard library.  No<br />
-      standard header refers to any of them.<br />
-<br />
-  scripts<br />
-    Scripts that are used during the configure, build, make, or test<br />
-    process.<br />
-<br />
-  src<br />
-    Files that are used in constructing the library, but are not<br />
-    installed.<br />
-<br />
-  testsuites/[backward, demangle, ext, performance, thread, 17_* to 27_*]<br />
-    Test programs are here, and may be used to begin to exercise the <br />
-    library.  Support for "make check" and "make check-install" is<br />
-    complete, and runs through all the subdirectories here when this<br />
-    command is issued from the build directory.  Please note that<br />
-    "make check" requires DejaGNU 1.4 or later to be installed.  Please<br />
-    note that "make check-script" calls the script mkcheck, which<br />
-    requires bash, and which may need the paths to bash adjusted to<br />
-    work properly, as /bin/bash is assumed.<br />
-<br />
-Other subdirectories contain variant versions of certain files<br />
-that are meant to be copied or linked by the configure script.<br />
-Currently these are:<br />
-<br />
-  config/abi<br />
-  config/cpu<br />
-  config/io<br />
-  config/locale<br />
-  config/os<br />
-<br />
-In addition, a subdirectory holds the convenience library libsupc++.<br />
-<br />
-  libsupc++<br />
-    Contains the runtime library for C++, including exception<br />
-    handling and memory allocation and deallocation, RTTI, terminate<br />
-    handlers, etc.<br />
-<br />
-Note that glibc also has a bits/ subdirectory.  We will either<br />
-need to be careful not to collide with names in its bits/<br />
-directory; or rename bits to (e.g.) cppbits/.<br />
-<br />
-In files throughout the system, lines marked with an "XXX" indicate<br />
-a bug or incompletely-implemented feature.  Lines marked "XXX MT"<br />
-indicate a place that may require attention for multi-thread safety.<br />
-  </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="appendix_contributing.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_contributing.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="source_code_style.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Appendix A. 
- Contributing
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Coding Style</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/spine.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/spine.html
deleted file mode 100644
index 643c8a7d5..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/spine.html
+++ /dev/null
@@ -1,57 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The GNU C++ Library</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="prev" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="next" href="intro.html" title="Part I.  Introduction" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">The GNU C++ Library</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="../spine.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="intro.html">Next</a></td></tr></table><hr /></div><div class="book" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual-index"></a>The GNU C++ Library</h1></div><div><p class="copyright">Copyright © 2009
- <a class="ulink" href="http://fsf.org" target="_top">FSF</a>
- </p></div><div><div class="legalnotice"><a id="id481533"></a><p>
- <a class="link" href="license.html" title="License">License</a>
- </p></div></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="part"><a href="intro.html">I.
- Introduction
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="status.html">1. Status</a></span></dt><dd><dl><dt><span class="sect1"><a href="status.html#manual.intro.status.standard">Implementation Status</a></span></dt><dd><dl><dt><span class="sect2"><a href="status.html#manual.intro.status.standard.1998">C++ 1998/2003</a></span></dt><dt><span class="sect2"><a href="status.html#manual.intro.status.standard.tr1">C++ TR1</a></span></dt><dt><span class="sect2"><a href="status.html#manual.intro.status.standard.200x">C++ 200x</a></span></dt></dl></dd><dt><span class="sect1"><a href="license.html">License</a></span></dt><dd><dl><dt><span class="sect2"><a href="license.html#manual.intro.status.license.gpl">The Code: GPL</a></span></dt><dt><span class="sect2"><a href="license.html#manual.intro.status.license.fdl">The Documentation: GPL, FDL</a></span></dt></dl></dd><dt><span class="sect1"><a href="bugs.html">Bugs</a></span></dt><dd><dl><dt><span class="sect2"><a href="bugs.html#manual.intro.status.bugs.impl">Implementation Bugs</a></span></dt><dt><span class="sect2"><a href="bugs.html#manual.intro.status.bugs.iso">Standard Bugs</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="setup.html">2. Setup</a></span></dt><dd><dl><dt><span class="sect1"><a href="setup.html#manual.intro.setup.prereq">Prerequisites</a></span></dt><dt><span class="sect1"><a href="configure.html">Configure</a></span></dt><dt><span class="sect1"><a href="make.html">Make</a></span></dt><dt><span class="sect1"><a href="test.html">Test</a></span></dt><dd><dl><dt><span class="sect2"><a href="test.html#test.organization">Organization</a></span></dt><dt><span class="sect2"><a href="test.html#test.run">Running the Testsuite</a></span></dt><dt><span class="sect2"><a href="test.html#test.new_tests">Writing a new test case</a></span></dt><dt><span class="sect2"><a href="test.html#test.harness">Test Harness and Utilities</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="using.html">3. Using</a></span></dt><dd><dl><dt><span class="sect1"><a href="using.html#manual.intro.using.lib">Linking Library Binary Files</a></span></dt><dt><span class="sect1"><a href="using_headers.html">Headers</a></span></dt><dd><dl><dt><span class="sect2"><a href="using_headers.html#manual.intro.using.headers.all">Header Files</a></span></dt><dt><span class="sect2"><a href="using_headers.html#manual.intro.using.headers.mixing">Mixing Headers</a></span></dt><dt><span class="sect2"><a href="using_headers.html#manual.intro.using.headers.cheaders">The C Headers and namespace std</a></span></dt><dt><span class="sect2"><a href="using_headers.html#manual.intro.using.headers.pre">Precompiled Headers</a></span></dt></dl></dd><dt><span class="sect1"><a href="using_namespaces.html">Namespaces</a></span></dt><dd><dl><dt><span class="sect2"><a href="using_namespaces.html#manual.intro.using.namespaces.all">Available Namespaces</a></span></dt><dt><span class="sect2"><a href="using_namespaces.html#manual.intro.using.namespaces.std">namespace std</a></span></dt><dt><span class="sect2"><a href="using_namespaces.html#manual.intro.using.namespaces.comp">Using Namespace Composition</a></span></dt></dl></dd><dt><span class="sect1"><a href="using_macros.html">Macros</a></span></dt><dt><span class="sect1"><a href="using_concurrency.html">Concurrency</a></span></dt><dd><dl><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.prereq">Prerequisites</a></span></dt><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.thread_safety">Thread Safety</a></span></dt><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.atomics">Atomics</a></span></dt><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.io">IO</a></span></dt><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.containers">Containers</a></span></dt></dl></dd><dt><span class="sect1"><a href="using_exceptions.html">Exceptions</a></span></dt><dd><dl><dt><span class="sect2"><a href="using_exceptions.html#intro.using.exception.propagating">Propagating Exceptions aka Exception Neutrality</a></span></dt><dt><span class="sect2"><a href="using_exceptions.html#intro.using.exception.safety">Exception Safety</a></span></dt><dt><span class="sect2"><a href="using_exceptions.html#intro.using.exception.no">Support for -fno-exceptions</a></span></dt></dl></dd><dt><span class="sect1"><a href="debug.html">Debugging Support</a></span></dt><dd><dl><dt><span class="sect2"><a href="debug.html#debug.compiler">Using g++</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.req">Debug Versions of Library Binary Files</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.memory">Memory Leak Hunting</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.gdb">Using gdb</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.exceptions">Tracking uncaught exceptions</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.debug_mode">Debug Mode</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.compile_time_checks">Compile Time Checking</a></span></dt></dl></dd></dl></dd></dl></dd><dt><span class="part"><a href="support.html">II.
- Support
-
-</a></span></dt><dd><dl><dt><span class="preface"><a href="bk01pt02pr01.html"></a></span></dt><dt><span class="chapter"><a href="fundamental_types.html">4. Types</a></span></dt><dd><dl><dt><span class="sect1"><a href="fundamental_types.html#manual.support.types.fundamental">Fundamental Types</a></span></dt><dt><span class="sect1"><a href="bk01pt02ch04s02.html">Numeric Properties</a></span></dt><dt><span class="sect1"><a href="bk01pt02ch04s03.html">NULL</a></span></dt></dl></dd><dt><span class="chapter"><a href="dynamic_memory.html">5. Dynamic Memory</a></span></dt><dt><span class="chapter"><a href="termination.html">6. Termination</a></span></dt><dd><dl><dt><span class="sect1"><a href="termination.html#support.termination.handlers">Termination Handlers</a></span></dt><dt><span class="sect1"><a href="verbose_termination.html">Verbose Terminate Handler</a></span></dt></dl></dd></dl></dd><dt><span class="part"><a href="diagnostics.html">III.
- Diagnostics
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="exceptions.html">7. Exceptions</a></span></dt><dd><dl><dt><span class="sect1"><a href="exceptions.html#manual.diagnostics.exceptions.hierarchy">Exception Classes</a></span></dt><dt><span class="sect1"><a href="bk01pt03ch07s02.html">Adding Data to Exceptions</a></span></dt><dt><span class="sect1"><a href="bk01pt03ch07s03.html">Cancellation</a></span></dt></dl></dd><dt><span class="chapter"><a href="bk01pt03ch08.html">8. Concept Checking</a></span></dt></dl></dd><dt><span class="part"><a href="utilities.html">IV.
- Utilities
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="functors.html">9. Functors</a></span></dt><dt><span class="chapter"><a href="pairs.html">10. Pairs</a></span></dt><dt><span class="chapter"><a href="memory.html">11. Memory</a></span></dt><dd><dl><dt><span class="sect1"><a href="memory.html#manual.util.memory.allocator">Allocators</a></span></dt><dd><dl><dt><span class="sect2"><a href="memory.html#allocator.req">Requirements</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.using">Using a Specific Allocator</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.custom">Custom Allocators</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.ext">Extension Allocators</a></span></dt></dl></dd><dt><span class="sect1"><a href="auto_ptr.html">auto_ptr</a></span></dt><dd><dl><dt><span class="sect2"><a href="auto_ptr.html#auto_ptr.limitations">Limitations</a></span></dt><dt><span class="sect2"><a href="auto_ptr.html#auto_ptr.using">Use in Containers</a></span></dt></dl></dd><dt><span class="sect1"><a href="shared_ptr.html">shared_ptr</a></span></dt><dd><dl><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.req">Requirements</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.using">Use</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.ack">Acknowledgments</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="traits.html">12. Traits</a></span></dt></dl></dd><dt><span class="part"><a href="strings.html">V.
- Strings
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="bk01pt05ch13.html">13. String Classes</a></span></dt><dd><dl><dt><span class="sect1"><a href="bk01pt05ch13.html#strings.string.simple">Simple Transformations</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s02.html">Case Sensitivity</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s03.html">Arbitrary Character Types</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s04.html">Tokenizing</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s05.html">Shrink to Fit</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s06.html">CString (MFC)</a></span></dt></dl></dd></dl></dd><dt><span class="part"><a href="localization.html">VI.
- Localization
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="locales.html">14. Locales</a></span></dt><dd><dl><dt><span class="sect1"><a href="locales.html#manual.localization.locales.locale">locale</a></span></dt><dd><dl><dt><span class="sect2"><a href="locales.html#locales.locale.req">Requirements</a></span></dt><dt><span class="sect2"><a href="locales.html#locales.locale.design">Design</a></span></dt><dt><span class="sect2"><a href="locales.html#locales.locale.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="locales.html#locales.locale.future">Future</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="facets.html">15. Facets aka Categories</a></span></dt><dd><dl><dt><span class="sect1"><a href="facets.html#manual.localization.facet.ctype">ctype</a></span></dt><dd><dl><dt><span class="sect2"><a href="facets.html#facet.ctype.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="facets.html#facet.ctype.future">Future</a></span></dt></dl></dd><dt><span class="sect1"><a href="codecvt.html">codecvt</a></span></dt><dd><dl><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.req">Requirements</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.design">Design</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.use">Use</a></span></dt><dt><span class="sect2"><a href="codecvt.html#facet.codecvt.future">Future</a></span></dt></dl></dd><dt><span class="sect1"><a href="messages.html">messages</a></span></dt><dd><dl><dt><span class="sect2"><a href="messages.html#facet.messages.req">Requirements</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.design">Design</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.use">Use</a></span></dt><dt><span class="sect2"><a href="messages.html#facet.messages.future">Future</a></span></dt></dl></dd></dl></dd></dl></dd><dt><span class="part"><a href="containers.html">VII.
- Containers
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="sequences.html">16. Sequences</a></span></dt><dd><dl><dt><span class="sect1"><a href="sequences.html#containers.sequences.list">list</a></span></dt><dd><dl><dt><span class="sect2"><a href="sequences.html#sequences.list.size">list::size() is O(n)</a></span></dt></dl></dd><dt><span class="sect1"><a href="vector.html">vector</a></span></dt><dd><dl><dt><span class="sect2"><a href="vector.html#sequences.vector.management">Space Overhead Management</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="associative.html">17. Associative</a></span></dt><dd><dl><dt><span class="sect1"><a href="associative.html#containers.associative.insert_hints">Insertion Hints</a></span></dt><dt><span class="sect1"><a href="bitset.html">bitset</a></span></dt><dd><dl><dt><span class="sect2"><a href="bitset.html#associative.bitset.size_variable">Size Variable</a></span></dt><dt><span class="sect2"><a href="bitset.html#associative.bitset.type_string">Type String</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="containers_and_c.html">18. Interacting with C</a></span></dt><dd><dl><dt><span class="sect1"><a href="containers_and_c.html#containers.c.vs_array">Containers vs. Arrays</a></span></dt></dl></dd></dl></dd><dt><span class="part"><a href="iterators.html">VIII.
- Iterators
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="bk01pt08ch19.html">19. Predefined</a></span></dt><dd><dl><dt><span class="sect1"><a href="bk01pt08ch19.html#iterators.predefined.vs_pointers">Iterators vs. Pointers</a></span></dt><dt><span class="sect1"><a href="bk01pt08ch19s02.html">One Past the End</a></span></dt></dl></dd></dl></dd><dt><span class="part"><a href="algorithms.html">IX.
- Algorithms
-
-</a></span></dt><dd><dl><dt><span class="preface"><a href="bk01pt09pr02.html"></a></span></dt><dt><span class="chapter"><a href="bk01pt09ch20.html">20. Mutating</a></span></dt><dd><dl><dt><span class="sect1"><a href="bk01pt09ch20.html#algorithms.mutating.swap">swap</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt09ch20.html#algorithms.swap.specializations">Specializations</a></span></dt></dl></dd></dl></dd></dl></dd><dt><span class="part"><a href="numerics.html">X.
- Numerics
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="complex.html">21. Complex</a></span></dt><dd><dl><dt><span class="sect1"><a href="complex.html#numerics.complex.processing">complex Processing</a></span></dt></dl></dd><dt><span class="chapter"><a href="generalized_numeric_operations.html">22. Generalized Operations</a></span></dt><dt><span class="chapter"><a href="numerics_and_c.html">23. Interacting with C</a></span></dt><dd><dl><dt><span class="sect1"><a href="numerics_and_c.html#numerics.c.array">Numerics vs. Arrays</a></span></dt><dt><span class="sect1"><a href="bk01pt10ch23s02.html">C99</a></span></dt></dl></dd></dl></dd><dt><span class="part"><a href="io.html">XI.
- Input and Output
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="iostream_objects.html">24. Iostream Objects</a></span></dt><dt><span class="chapter"><a href="streambufs.html">25. Stream Buffers</a></span></dt><dd><dl><dt><span class="sect1"><a href="streambufs.html#io.streambuf.derived">Derived streambuf Classes</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch25s02.html">Buffering</a></span></dt></dl></dd><dt><span class="chapter"><a href="stringstreams.html">26. Memory Based Streams</a></span></dt><dd><dl><dt><span class="sect1"><a href="stringstreams.html#manual.io.memstreams.compat">Compatibility With strstream</a></span></dt></dl></dd><dt><span class="chapter"><a href="fstreams.html">27. File Based Streams</a></span></dt><dd><dl><dt><span class="sect1"><a href="fstreams.html#manual.io.filestreams.copying_a_file">Copying a File</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch27s02.html">Binary Input and Output</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch27s03.html">More Binary Input and Output</a></span></dt></dl></dd><dt><span class="chapter"><a href="io_and_c.html">28. Interacting with C</a></span></dt><dd><dl><dt><span class="sect1"><a href="io_and_c.html#manual.io.c.FILE">Using FILE* and file descriptors</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch28s02.html">Performance</a></span></dt></dl></dd></dl></dd><dt><span class="part"><a href="extensions.html">XII.
- Extensions
-
-</a></span></dt><dd><dl><dt><span class="preface"><a href="bk01pt12pr03.html"></a></span></dt><dt><span class="chapter"><a href="ext_compile_checks.html">29. Compile Time Checks</a></span></dt><dt><span class="chapter"><a href="debug_mode.html">30. Debug Mode</a></span></dt><dd><dl><dt><span class="sect1"><a href="debug_mode.html#manual.ext.debug_mode.intro">Intro</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch30s02.html">Semantics</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch30s03.html">Using</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch30s03.html#debug_mode.using.mode">Using the Debug Mode</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch30s03.html#debug_mode.using.specific">Using a Specific Debug Container</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch30s04.html">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch30s04.html#manual.ext.debug_mode.design.goals">Goals</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch30s04.html#manual.ext.debug_mode.design.methods">Methods</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch30s04.html#manual.ext.debug_mode.design.other">Other Implementations</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="parallel_mode.html">31. Parallel Mode</a></span></dt><dd><dl><dt><span class="sect1"><a href="parallel_mode.html#manual.ext.parallel_mode.intro">Intro</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch31s02.html">Semantics</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch31s03.html">Using</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch31s03.html#parallel_mode.using.prereq_flags">Prerequisite Compiler Flags</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch31s03.html#parallel_mode.using.parallel_mode">Using Parallel Mode</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch31s03.html#parallel_mode.using.specific">Using Specific Parallel Components</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch31s04.html">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch31s04.html#manual.ext.parallel_mode.design.intro">Interface Basics</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch31s04.html#manual.ext.parallel_mode.design.tuning">Configuration and Tuning</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch31s04.html#manual.ext.parallel_mode.design.impl">Implementation Namespaces</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch31s05.html">Testing</a></span></dt><dt><span class="bibliography"><a href="parallel_mode.html#parallel_mode.biblio">Bibliography</a></span></dt></dl></dd><dt><span class="chapter"><a href="ext_allocators.html">32. Allocators</a></span></dt><dd><dl><dt><span class="sect1"><a href="ext_allocators.html#manual.ext.allocator.mt">mt_allocator</a></span></dt><dd><dl><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.intro">Intro</a></span></dt><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.example_single">Single Thread Example</a></span></dt><dt><span class="sect2"><a href="ext_allocators.html#allocator.mt.example_multi">Multiple Thread Example</a></span></dt></dl></dd><dt><span class="sect1"><a href="bitmap_allocator.html">bitmap_allocator</a></span></dt><dd><dl><dt><span class="sect2"><a href="bitmap_allocator.html#allocator.bitmap.design">Design</a></span></dt><dt><span class="sect2"><a href="bitmap_allocator.html#allocator.bitmap.impl">Implementation</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="ext_containers.html">33. Containers</a></span></dt><dd><dl><dt><span class="sect1"><a href="ext_containers.html#manual.ext.containers.pbds">Policy Based Data Structures</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch33s02.html">HP/SGI</a></span></dt><dt><span class="sect1"><a href="bk01pt12ch33s03.html">Deprecated HP/SGI</a></span></dt></dl></dd><dt><span class="chapter"><a href="ext_utilities.html">34. Utilities</a></span></dt><dt><span class="chapter"><a href="ext_algorithms.html">35. Algorithms</a></span></dt><dt><span class="chapter"><a href="ext_numerics.html">36. Numerics</a></span></dt><dt><span class="chapter"><a href="ext_iterators.html">37. Iterators</a></span></dt><dt><span class="chapter"><a href="ext_io.html">38. Input and Output</a></span></dt><dd><dl><dt><span class="sect1"><a href="ext_io.html#manual.ext.io.filebuf_derived">Derived filebufs</a></span></dt></dl></dd><dt><span class="chapter"><a href="ext_demangling.html">39. Demangling</a></span></dt><dt><span class="chapter"><a href="ext_concurrency.html">40. Concurrency</a></span></dt><dd><dl><dt><span class="sect1"><a href="ext_concurrency.html#manual.ext.concurrency.design">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="ext_concurrency.html#manual.ext.concurrency.design.threads">Interface to Locks and Mutexes</a></span></dt><dt><span class="sect2"><a href="ext_concurrency.html#manual.ext.concurrency.design.atomics">Interface to Atomic Functions</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch40s02.html">Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="bk01pt12ch40s02.html#manual.ext.concurrency.impl.atomic_fallbacks">Using Builtin Atomic Functions</a></span></dt><dt><span class="sect2"><a href="bk01pt12ch40s02.html#manual.ext.concurrency.impl.thread">Thread Abstraction</a></span></dt></dl></dd><dt><span class="sect1"><a href="bk01pt12ch40s03.html">Use</a></span></dt></dl></dd></dl></dd><dt><span class="appendix"><a href="appendix_contributing.html">A.
- Contributing
-
-</a></span></dt><dd><dl><dt><span class="sect1"><a href="appendix_contributing.html#contrib.list">Contributor Checklist</a></span></dt><dd><dl><dt><span class="sect2"><a href="appendix_contributing.html#list.reading">Reading</a></span></dt><dt><span class="sect2"><a href="appendix_contributing.html#list.copyright">Assignment</a></span></dt><dt><span class="sect2"><a href="appendix_contributing.html#list.getting">Getting Sources</a></span></dt><dt><span class="sect2"><a href="appendix_contributing.html#list.patches">Submitting Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="source_organization.html">Directory Layout and Source Conventions</a></span></dt><dt><span class="sect1"><a href="source_code_style.html">Coding Style</a></span></dt><dd><dl><dt><span class="sect2"><a href="source_code_style.html#coding_style.bad_identifiers">Bad Identifiers</a></span></dt><dt><span class="sect2"><a href="source_code_style.html#coding_style.example">By Example</a></span></dt></dl></dd><dt><span class="sect1"><a href="documentation_style.html">Documentation Style</a></span></dt><dd><dl><dt><span class="sect2"><a href="documentation_style.html#doc_style.doxygen">Doxygen</a></span></dt><dt><span class="sect2"><a href="documentation_style.html#doc_style.docbook">Docbook</a></span></dt></dl></dd><dt><span class="sect1"><a href="source_design_notes.html">Design Notes</a></span></dt></dl></dd><dt><span class="appendix"><a href="appendix_porting.html">B.
- Porting and Maintenance
-
-</a></span></dt><dd><dl><dt><span class="sect1"><a href="appendix_porting.html#appendix.porting.build_hacking">Configure and Build Hacking</a></span></dt><dd><dl><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.prereq">Prerequisites</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.map">Overview: What Comes from Where</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.scripts">Storing Information in non-AC files (like configure.host)</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.conventions">Coding and Commenting Conventions</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.acinclude">The acinclude.m4 layout</a></span></dt><dt><span class="sect2"><a href="appendix_porting.html#build_hacking.enable">GLIBCXX_ENABLE, the --enable maker</a></span></dt></dl></dd><dt><span class="sect1"><a href="internals.html">Porting to New Hardware or Operating Systems</a></span></dt><dd><dl><dt><span class="sect2"><a href="internals.html#internals.os">Operating System</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.cpu">CPU</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.char_types">Character Types</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.thread_safety">Thread Safety</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.numeric_limits">Numeric Limits</a></span></dt><dt><span class="sect2"><a href="internals.html#internals.libtool">Libtool</a></span></dt></dl></dd><dt><span class="sect1"><a href="abi.html">ABI Policy and Guidelines</a></span></dt><dd><dl><dt><span class="sect2"><a href="abi.html#abi.cxx_interface">The C++ Interface</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.versioning">Versioning</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.changes_allowed">Allowed Changes</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.changes_no">Prohibited Changes</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.testing">Testing</a></span></dt><dt><span class="sect2"><a href="abi.html#abi.issues">Outstanding Issues</a></span></dt></dl></dd><dt><span class="sect1"><a href="api.html">API Evolution and Deprecation History</a></span></dt><dd><dl><dt><span class="sect2"><a href="api.html#api.rel_300">3.0</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_310">3.1</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_320">3.2</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_330">3.3</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_340">3.4</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_400">4.0</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_410">4.1</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_420">4.2</a></span></dt><dt><span class="sect2"><a href="api.html#api.rel_430">4.3</a></span></dt></dl></dd><dt><span class="sect1"><a href="backwards.html">Backwards Compatibility</a></span></dt><dd><dl><dt><span class="sect2"><a href="backwards.html#backwards.first">First</a></span></dt><dt><span class="sect2"><a href="backwards.html#backwards.second">Second</a></span></dt><dt><span class="sect2"><a href="backwards.html#backwards.third">Third</a></span></dt></dl></dd></dl></dd><dt><span class="appendix"><a href="appendix_free.html">C.
- Free Software Needs Free Documentation
-
-</a></span></dt><dt><span class="appendix"><a href="appendix_gpl.html">D.
- GNU General Public License version 3
- </a></span></dt><dt><span class="appendix"><a href="appendix_gfdl.html">E. GNU Free Documentation License</a></span></dt><dt><span class="index"><a href="bk01ix01.html">Index</a></span></dt></dl></div><div class="list-of-tables"><p><b>List of Tables</b></p><dl><dt>1.1. <a href="status.html#id409772">C++ 1998/2003 Implementation Status</a></dt><dt>1.2. <a href="status.html#id483804">C++ TR1 Implementation Status</a></dt><dt>1.3. <a href="status.html#id399999">C++ 200x Implementation Status</a></dt><dt>3.1. <a href="using_headers.html#id425445">C++ 1998 Library Headers</a></dt><dt>3.2. <a href="using_headers.html#id401915">C++ 1998 Library Headers for C Library Facilities</a></dt><dt>3.3. <a href="using_headers.html#id400861">C++ 200x Library Headers</a></dt><dt>3.4. <a href="using_headers.html#id419917">C++ 200x Library Headers for C Library Facilities</a></dt><dt>3.5. <a href="using_headers.html#id409697">C++ TR1 Library Headers</a></dt><dt>3.6. <a href="using_headers.html#id458482">C++ TR1 Library Headers for C Library Facilities</a></dt><dt>3.7. <a href="using_headers.html#id406531">C++ ABI Headers</a></dt><dt>3.8. <a href="using_headers.html#id519638">Extension Headers</a></dt><dt>3.9. <a href="using_headers.html#id423635">Extension Debug Headers</a></dt><dt>3.10. <a href="using_headers.html#id410706">Extension Parallel Headers</a></dt><dt>30.1. <a href="bk01pt12ch30s03.html#id455307">Debugging Containers</a></dt><dt>30.2. <a href="bk01pt12ch30s03.html#id393058">Debugging Containers C++0x</a></dt><dt>31.1. <a href="bk01pt12ch31s03.html#id388611">Parallel Algorithms</a></dt><dt>32.1. <a href="bitmap_allocator.html#id435115">Bitmap Allocator Memory Map</a></dt><dt>A.1. <a href="documentation_style.html#id435551">HTML to Docbook XML markup comparison</a></dt><dt>A.2. <a href="documentation_style.html#id500888">Docbook XML Element Use</a></dt><dt>B.1. <a href="api.html#id433248">Extension Allocators</a></dt><dt>B.2. <a href="api.html#id433479">Extension Allocators Continued</a></dt></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="../spine.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="intro.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">The GNU C++ Library Documentation </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part I. 
- Introduction
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/status.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/status.html
deleted file mode 100644
index f967fc04d..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/status.html
+++ /dev/null
@@ -1,237 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 1. Status</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="intro.html" title="Part I.  Introduction" /><link rel="prev" href="intro.html" title="Part I.  Introduction" /><link rel="next" href="license.html" title="License" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 1. Status</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="intro.html">Prev</a> </td><th width="60%" align="center">Part I. 
- Introduction
-
-</th><td width="20%" align="right"> <a accesskey="n" href="license.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.intro.status"></a>Chapter 1. Status</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="status.html#manual.intro.status.standard">Implementation Status</a></span></dt><dd><dl><dt><span class="sect2"><a href="status.html#manual.intro.status.standard.1998">C++ 1998/2003</a></span></dt><dt><span class="sect2"><a href="status.html#manual.intro.status.standard.tr1">C++ TR1</a></span></dt><dt><span class="sect2"><a href="status.html#manual.intro.status.standard.200x">C++ 200x</a></span></dt></dl></dd><dt><span class="sect1"><a href="license.html">License</a></span></dt><dd><dl><dt><span class="sect2"><a href="license.html#manual.intro.status.license.gpl">The Code: GPL</a></span></dt><dt><span class="sect2"><a href="license.html#manual.intro.status.license.fdl">The Documentation: GPL, FDL</a></span></dt></dl></dd><dt><span class="sect1"><a href="bugs.html">Bugs</a></span></dt><dd><dl><dt><span class="sect2"><a href="bugs.html#manual.intro.status.bugs.impl">Implementation Bugs</a></span></dt><dt><span class="sect2"><a href="bugs.html#manual.intro.status.bugs.iso">Standard Bugs</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.status.standard"></a>Implementation Status</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.standard.1998"></a>C++ 1998/2003</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="standard.1998.status"></a>Implementation Status</h4></div></div></div><p>
-This status table is based on the table of contents of ISO/IEC 14882:2003.
-</p><p>
-This page describes the C++0x support in mainline GCC SVN, not in any
-particular release.
-</p><div class="table"><a id="id409772"></a><p class="title"><b>Table 1.1. C++ 1998/2003 Implementation Status</b></p><div class="table-contents"><table summary="C++ 1998/2003 Implementation Status" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><thead><tr><th align="left">Section</th><th align="left">Description</th><th align="left">Status</th><th align="left">Comments</th></tr></thead><tbody><tr><td align="left">
- <span class="emphasis"><em>18</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Language support</em></span>
- </td></tr><tr><td align="left">18.1</td><td align="left">Types</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.2</td><td align="left">Implementation properties</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.2.1</td><td align="left">Numeric Limits</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">18.2.1.1</td><td align="left">Class template <code class="code">numeric_limits</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.2.1.2</td><td align="left"><code class="code">numeric_limits</code> members</td><td align="left">Y</td><td class="auto-generated"> </td></tr><tr><td align="left">18.2.1.3</td><td align="left"><code class="code">float_round_style</code></td><td align="left">Y</td><td class="auto-generated"> </td></tr><tr><td align="left">18.2.1.4</td><td align="left"><code class="code">float_denorm_style</code></td><td align="left">Y</td><td class="auto-generated"> </td></tr><tr><td align="left">18.2.1.5</td><td align="left"><code class="code">numeric_limits</code> specializations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.2.2</td><td align="left">C Library</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.3</td><td align="left">Start and termination</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.4</td><td align="left">Dynamic memory management</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.5</td><td align="left">Type identification</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">18.5.1</td><td align="left">Class type_info</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.5.2</td><td align="left">Class bad_cast</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.5.3</td><td align="left">Class bad_typeid</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.6</td><td align="left">Exception handling</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">18.6.1</td><td align="left">Class exception</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.6.2</td><td align="left">Violation exception-specifications</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.6.3</td><td align="left">Abnormal termination</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.6.4</td><td align="left"><code class="code">uncaught_exception</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.7</td><td align="left">Other runtime support</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>19</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Diagnostics</em></span>
- </td></tr><tr><td align="left">19.1</td><td align="left">Exception classes</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">19.2</td><td align="left">Assertions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">19.3</td><td align="left">Error numbers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>20</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>General utilities</em></span>
- </td></tr><tr><td align="left">20.1</td><td align="left">Requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.2</td><td align="left">Utility components</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.2.1</td><td align="left">Operators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.2.2</td><td align="left"><code class="code">pair</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.3</td><td align="left">Function objects</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.3.1</td><td align="left">Base</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.3.2</td><td align="left">Arithmetic operation</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.3.3</td><td align="left">Comparisons</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.3.4</td><td align="left">Logical operations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.3.5</td><td align="left">Negators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.3.6</td><td align="left">Binders</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.3.7</td><td align="left">Adaptors for pointers to functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.3.8</td><td align="left">Adaptors for pointers to members</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4</td><td align="left">Memory</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.4.1</td><td align="left">The default allocator</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4.2</td><td align="left">Raw storage iterator</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4.3</td><td align="left">Temporary buffers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4.4</td><td align="left">Specialized algorithms</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4.4.1</td><td align="left"><code class="code">uninitialized_copy</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4.4.2</td><td align="left"><code class="code">uninitialized_fill</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4.4.3</td><td align="left"><code class="code">uninitialized_fill_n</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4.5</td><td align="left">Class template <code class="code">auto_ptr</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4.6</td><td align="left">C library</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>21</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Strings</em></span>
- </td></tr><tr><td align="left">21.1</td><td align="left">Character traits</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">21.1.1</td><td align="left">Character traits requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.1.2</td><td align="left">traits typedef</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.1.3</td><td align="left"><code class="code">char_traits</code> specializations</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">21.1.3.1</td><td align="left">struct <code class="code">char_traits&lt;char&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.1.3.2</td><td align="left">struct <code class="code">char_traits&lt;wchar_t&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.2</td><td align="left">String classes</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.3</td><td align="left">Class template <code class="code">basic_string</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.4</td><td align="left">Null-terminated sequence utilities</td><td align="left">Y</td><td align="left">C library dependency</td></tr><tr><td align="left">
- <span class="emphasis"><em>22</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Localization</em></span>
- </td></tr><tr><td align="left">22.1</td><td align="left">Locales</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.1.1</td><td align="left">Class <code class="code">locale</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.1.2</td><td align="left"><code class="code">locale</code> globals</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.1.3</td><td align="left">Convenience interfaces</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.1.3.1</td><td align="left">Character classification</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.1.3.2</td><td align="left">Character conversions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2</td><td align="left">Standard locale categories</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.2.1</td><td align="left"><code class="code">ctype</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.2</td><td align="left">Numeric</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.2.2.1</td><td align="left"><code class="code">num_get</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.2.2</td><td align="left"><code class="code">num_put</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.3</td><td align="left"><code class="code">num_punct</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.4</td><td align="left"><code class="code">collate</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.5</td><td align="left">Time</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.2.5.1</td><td align="left"><code class="code">time_get</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.5.2</td><td align="left"><code class="code">time_get_byname</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.5.3</td><td align="left"><code class="code">time_put</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.5.3</td><td align="left"><code class="code">time_put_byname</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.6</td><td align="left">Monetary</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.2.6.1</td><td align="left"><code class="code">money_get</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.6.2</td><td align="left"><code class="code">money_put</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.6.3</td><td align="left"><code class="code">money_punct</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.6.4</td><td align="left"><code class="code">money_punct_byname</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.7</td><td align="left"><code class="code">messages</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2.8</td><td align="left">Program-defined facets</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.3</td><td align="left">C Library Locales</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>23</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Containers</em></span>
- </td></tr><tr><td align="left">23.1</td><td align="left">Container requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.2</td><td align="left">Sequence containers</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">23.2.1</td><td align="left">Class template <code class="code">deque</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.2.2</td><td align="left">Class template <code class="code">list</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.2.3</td><td align="left">Adaptors</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">23.2.3.1</td><td align="left">Class template <code class="code">queue</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.2.3.2</td><td align="left">Class template <code class="code">priority_queue</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.2.3.3</td><td align="left">Class template <code class="code">stack</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.2.4</td><td align="left">Class template <code class="code">vector</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.2.5</td><td align="left">Class <code class="code">vector&lt;bool&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3</td><td align="left">Associative containers</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">23.3.1</td><td align="left">Class template <code class="code">map</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3.2</td><td align="left">Class template <code class="code">multimap</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3.3</td><td align="left">Class template <code class="code">set</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3.4</td><td align="left">Class template <code class="code">multiset</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>24</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Iterators</em></span>
- </td></tr><tr><td align="left">24.1</td><td align="left">Requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.2</td><td align="left">Header <code class="code">&lt;iterator&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.3</td><td align="left">Iterator primitives</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.4</td><td align="left">Predefined iterators and Iterator adaptors</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">24.4.1</td><td align="left">Reverse iterators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.4.2</td><td align="left">Insert iterators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.5</td><td align="left">Stream iterators</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">24.5.1</td><td align="left">Class template <code class="code">istream_iterator</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.5.2</td><td align="left">Class template <code class="code">ostream_iterator</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.5.3</td><td align="left">Class template <code class="code">istreambuf_iterator</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.5.4</td><td align="left">Class template <code class="code">ostreambuf_iterator</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>25</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Algorithms</em></span>
- </td></tr><tr><td align="left">25.1</td><td align="left">Non-modifying sequence operations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">25.2</td><td align="left">Mutating sequence operations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">25.3</td><td align="left">Sorting and related operations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">25.4</td><td align="left">C library algorithms</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>26</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Numerics</em></span>
- </td></tr><tr><td align="left">26.1</td><td align="left">Numeric type requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.2</td><td align="left">Complex numbers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.3</td><td align="left">Numeric arrays</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">26.3.1</td><td align="left">Header <code class="code">&lt;valarray&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.3.2</td><td align="left">Class template <code class="code">valarray</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.3.3</td><td align="left"><code class="code">valarray</code> non-member operations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.3.4</td><td align="left">Class <code class="code">slice</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.3.5</td><td align="left">Class template <code class="code">slice_array</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.3.6</td><td align="left">Class <code class="code">gslice</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.3.7</td><td align="left">Class template <code class="code">gslice_array</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.3.8</td><td align="left">Class template <code class="code">mask_array</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.3.9</td><td align="left">Class template <code class="code">indirect_array</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.4</td><td align="left">Generalized numeric operations</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">26.4.1</td><td align="left"><code class="code">accumulate</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.4.2</td><td align="left"><code class="code">inner_product</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.4.3</td><td align="left"><code class="code">partial_sum</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.4.4</td><td align="left"><code class="code">adjacent_difference</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.4.5</td><td align="left">iota</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.5</td><td align="left">C Library</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>27</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Input/output</em></span>
- </td></tr><tr><td align="left">27.1</td><td align="left">Requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.2</td><td align="left">Forward declarations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.3</td><td align="left">Standard iostream objects</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.3.1</td><td align="left">Narrow stream objects</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.3.2</td><td align="left">Wide stream objects</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.4</td><td align="left">Iostreams base classes</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.5</td><td align="left">Stream buffers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.6</td><td align="left">Formatting and manipulators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.7</td><td align="left">String-based streams</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.8</td><td align="left">File-based streams</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>Appendix D</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Compatibility features</em></span>
- </td></tr><tr><td align="left">D.1</td><td align="left">Increment operator with bool operand</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.2</td><td align="left"><code class="code">static</code> keyword</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.3</td><td align="left">Access declarations</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.4</td><td align="left">Implicit conversion from const strings</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.5</td><td align="left">C standard library headers</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.6</td><td align="left">Old iostreams members</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.7</td><td align="left">char* streams</td><td align="left"> </td><td align="left"> </td></tr></tbody></table></div></div><br class="table-break" /></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="standard.1998.specific"></a>Implementation Specific Behavior</h4></div></div></div><p>
- The ISO standard defines the following phrase:
- </p><div class="blockquote"><blockquote class="blockquote"><div class="variablelist"><dl><dt><span class="term">
- <code class="code">[1.3.5] implementation-defined behavior</code>
- </span></dt><dd><p>
- Behavior, for a well-formed program construct and correct data, that
- depends on the implementation <span class="emphasis"><em>and that each implementation
- shall document</em></span>.
- </p></dd></dl></div></blockquote></div><p>
- We do so here, for the C++ library only. Behavior of the
- compiler, linker, runtime loader, and other elements of "the
- implementation" are documented elsewhere. Everything listed
- in Annex B, Implementation Qualities, are also part of the
- compiler, not the library.
- </p><p>
- For each entry, we give the section number of the standard, when
- applicable. This list is probably incomplet and inkorrekt.
- </p><p>
- <span class="emphasis"><em>[1.9]/11 #3</em></span> If <code class="code">isatty(3)</code> is true, then
- interactive stream support is implied.
- </p><p>
- <span class="emphasis"><em>[17.4.4.5]</em></span> Non-reentrant functions are probably best
- discussed in the various sections on multithreading (see above).
- </p><p><span class="emphasis"><em>[18.1]/4</em></span> The type of <code class="code">NULL</code> is described
- <a class="ulink" href="../18_support/howto.html#1" target="_top">here</a>.
- </p><p><span class="emphasis"><em>[18.3]/8</em></span> Even though it's listed in the library
- sections, libstdc++ has zero control over what the cleanup code hands
- back to the runtime loader. Talk to the compiler people. :-)
- </p><p><span class="emphasis"><em>[18.4.2.1]/5</em></span> (bad_alloc),
- <span class="emphasis"><em>[18.5.2]/5</em></span> (bad_cast),
- <span class="emphasis"><em>[18.5.3]/5</em></span> (bad_typeid),
- <span class="emphasis"><em>[18.6.1]/8</em></span> (exception),
- <span class="emphasis"><em>[18.6.2.1]/5</em></span> (bad_exception): The <code class="code">what()</code>
- member function of class <code class="code">std::exception</code>, and these other
- classes publicly derived from it, simply returns the name of the
- class. But they are the <span class="emphasis"><em>mangled</em></span> names; you will need to call
- <code class="code">c++filt</code> and pass the names as command-line parameters to
- demangle them, or call a
- <a class="ulink" href="../18_support/howto.html#5" target="_top">runtime demangler function</a>.
- (The classes in <code class="code">&lt;stdexcept&gt;</code> have constructors which
- require an argument to use later for <code class="code">what()</code> calls, so the
- problem of <code class="code">what()</code>'s value does not arise in most
- user-defined exceptions.)
- </p><p><span class="emphasis"><em>[18.5.1]/7</em></span> The return value of
- <code class="code">std::type_info::name()</code> is the mangled type name (see the
- previous entry for more).
- </p><p><span class="emphasis"><em>[20.1.5]/5</em></span> <span class="emphasis"><em>"Implementors are encouraged to
- supply libraries that can accept allocators that encapsulate more
- general memory models and that support non-equal instances. In such
- implementations, any requirements imposed on allocators by containers
- beyond those requirements that appear in Table 32, and the semantics
- of containers and algorithms when allocator instances compare
- non-equal, are implementation-defined."</em></span> As yet we don't
- have any allocators which compare non-equal, so we can't describe how
- they behave.
- </p><p><span class="emphasis"><em>[21.1.3.1]/3,4</em></span>,
- <span class="emphasis"><em>[21.1.3.2]/2</em></span>,
- <span class="emphasis"><em>[23.*]'s foo::iterator</em></span>,
- <span class="emphasis"><em>[27.*]'s foo::*_type</em></span>,
- <span class="emphasis"><em>others...</em></span>
- Nope, these types are called implementation-defined because you
- shouldn't be taking advantage of their underlying types. Listing them
- here would defeat the purpose. :-)
- </p><p><span class="emphasis"><em>[21.1.3.1]/5</em></span> I don't really know about the mbstate_t
- stuff... see the <a class="ulink" href="../22_locale/howto.html" target="_top">chapter 22 notes</a>
- for what does exist.
- </p><p><span class="emphasis"><em>[22.*]</em></span> Anything and everything we have on locale
- implementation will be described
- <a class="ulink" href="../22_locale/howto.html" target="_top">over here</a>.
- </p><p><span class="emphasis"><em>[26.2.8]/9</em></span> I have no idea what
- <code class="code">complex&lt;T&gt;</code>'s pow(0,0) returns.
- </p><p><span class="emphasis"><em>[27.4.2.4]/2</em></span> Calling
- <code class="code">std::ios_base::sync_with_stdio</code> after I/O has already been
- performed on the standard stream objects will
- flush the buffers, and
- destroy and recreate the underlying buffer instances. Whether or not
- the previously-written I/O is destroyed in this process depends mostly
- on the --enable-libio choice: for stdio, if the written data is
- already in the stdio buffer, the data may be completely safe!
- </p><p><span class="emphasis"><em>[27.6.1.1.2]</em></span>,
- <span class="emphasis"><em>[27.6.2.3]</em></span> The I/O sentry ctor and dtor can perform
- additional work than the minimum required. We are not currently taking
- advantage of this yet.
- </p><p><span class="emphasis"><em>[27.7.1.3]/16</em></span>,
- <span class="emphasis"><em>[27.8.1.4]/10</em></span>
- The effects of <code class="code">pubsetbuf/setbuf</code> are described
- <a class="ulink" href="../27_io/howto.html#2" target="_top">in this chapter</a>.
- </p><p><span class="emphasis"><em>[27.8.1.4]/16</em></span> Calling <code class="code">fstream::sync</code> when
- a get area exists will... whatever <code class="code">fflush()</code> does, I think.
- </p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.standard.tr1"></a>C++ TR1</h3></div></div></div><p>
-This table is based on the table of contents of ISO/IEC DTR 19768
-Doc No: N1836=05-0096 Date: 2005-06-24
-Draft Technical Report on C++ Library Extensions
-</p><p>
-In this implementation the header names are prefixed by
-<code class="code">tr1/</code>, for instance <code class="code">&lt;tr1/functional&gt;</code>,
-<code class="code">&lt;tr1/memory&gt;</code>, and so on.
-</p><p>
-This page describes the TR1 support in mainline GCC SVN, not in any particular
-release.
-</p><div class="table"><a id="id483804"></a><p class="title"><b>Table 1.2. C++ TR1 Implementation Status</b></p><div class="table-contents"><table summary="C++ TR1 Implementation Status" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><thead><tr><th align="left">Section</th><th align="left">Description</th><th align="left">Status</th><th align="left">Comments</th></tr></thead><tbody><tr><td align="left"><span class="emphasis"><em>2</em></span></td><td colspan="3" align="left"><span class="emphasis"><em>General Utilities</em></span></td></tr><tr><td align="left">2.1</td><td align="left">Reference wrappers</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">2.1.1</td><td align="left">Additions to header <code class="code">&lt;functional&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.1.2</td><td align="left">Class template <code class="code">reference_wrapper</code></td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">2.1.2.1</td><td align="left"><code class="code">reference_wrapper</code> construct/copy/destroy</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.1.2.2</td><td align="left"><code class="code">reference_wrapper</code> assignment</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.1.2.3</td><td align="left"><code class="code">reference_wrapper</code> access</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.1.2.4</td><td align="left"><code class="code">reference_wrapper</code> invocation</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.1.2.5</td><td align="left"><code class="code">reference_wrapper</code> helper functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2</td><td align="left">Smart pointers</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">2.2.1</td><td align="left">Additions to header <code class="code">&lt;memory&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.2</td><td align="left">Class <code class="code">bad_weak_ptr</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.3</td><td align="left">Class template <code class="code">shared_ptr</code></td><td align="left"> </td><td align="left">
- <p>
- Uses code from
- <a class="ulink" href="http://www.boost.org/libs/smart_ptr/shared_ptr.htm" target="_top">boost::shared_ptr</a>.
- </p>
- </td></tr><tr><td align="left">2.2.3.1</td><td align="left"><code class="code">shared_ptr</code> constructors</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.3.2</td><td align="left"><code class="code">shared_ptr</code> destructor</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.3.3</td><td align="left"><code class="code">shared_ptr</code> assignment</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.3.4</td><td align="left"><code class="code">shared_ptr</code> modifiers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.3.5</td><td align="left"><code class="code">shared_ptr</code> observers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.3.6</td><td align="left"><code class="code">shared_ptr</code> comparison</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.3.7</td><td align="left"><code class="code">shared_ptr</code> I/O</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.3.8</td><td align="left"><code class="code">shared_ptr</code> specialized algorithms</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.3.9</td><td align="left"><code class="code">shared_ptr</code> casts</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.3.10</td><td align="left"><code class="code">get_deleter</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.4</td><td align="left">Class template <code class="code">weak_ptr</code></td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">2.2.4.1</td><td align="left"><code class="code">weak_ptr</code> constructors</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.4.2</td><td align="left"><code class="code">weak_ptr</code> destructor</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.4.3</td><td align="left"><code class="code">weak_ptr</code> assignment</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.4.4</td><td align="left"><code class="code">weak_ptr</code> modifiers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.4.5</td><td align="left"><code class="code">weak_ptr</code> observers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.4.6</td><td align="left"><code class="code">weak_ptr</code> comparison</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.4.7</td><td align="left"><code class="code">weak_ptr</code> specialized algorithms</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">2.2.5</td><td align="left">Class template <code class="code">enable_shared_from_this</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left"><span class="emphasis"><em>3</em></span></td><td colspan="3" align="left"><span class="emphasis"><em>Function Objects</em></span></td></tr><tr><td align="left">3.1</td><td align="left">Definitions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.2</td><td align="left">Additions to <code class="code">&lt;functional&gt; synopsis</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.3</td><td align="left">Requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.4</td><td align="left">Function return types</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.5</td><td align="left">Function template <code class="code">mem_fn</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.6</td><td align="left">Function object binders</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">3.6.1</td><td align="left">Class template <code class="code">is_bind_expression</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.6.2</td><td align="left">Class template <code class="code">is_placeholder</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.6.3</td><td align="left">Function template <code class="code">bind</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.6.4</td><td align="left">Placeholders</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.7</td><td align="left">Polymorphic function wrappers</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">3.7.1</td><td align="left">Class <code class="code">bad_function_call<code class="code"></code></code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.7.1.1</td><td align="left"><code class="code">bad_function_call</code> constructor</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.7.2</td><td align="left">Class template <code class="code">function</code></td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">3.7.2.1</td><td align="left"><code class="code">function</code> construct/copy/destroy</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.7.2.2</td><td align="left"><code class="code">function</code> modifiers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.7.2.3</td><td align="left"><code class="code">function</code> capacity</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.7.2.4</td><td align="left"><code class="code">function</code> invocation</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.7.2.5</td><td align="left"><code class="code">function</code> target access</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.7.2.6</td><td align="left">undefined operators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.7.2.7</td><td align="left">null pointer comparison operators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">3.7.2.8</td><td align="left">specialized algorithms</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left"><span class="emphasis"><em>4</em></span></td><td colspan="3" align="left"><span class="emphasis"><em>Metaprogramming and type traits</em></span></td></tr><tr><td align="left">4.1</td><td align="left">Requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.2</td><td align="left">Header <code class="code">&lt;type_traits&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.3</td><td align="left">Helper classes</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.4</td><td align="left">General Requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.5</td><td align="left">Unary Type Traits</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">4.5.1</td><td align="left">Primary Type Categories</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.5.2</td><td align="left">Composite type traits</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.5.3</td><td align="left">Type properties</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.6</td><td align="left">Relationships between types</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.7</td><td align="left">Transformations between types</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">4.7.1</td><td align="left">Const-volatile modifications</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.7.2</td><td align="left">Reference modifications</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.7.3</td><td align="left">Array modifications</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.7.4</td><td align="left">Pointer modifications</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.8</td><td align="left">Other transformations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">4.9</td><td align="left">Implementation requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left"><span class="emphasis"><em>5</em></span></td><td colspan="3" align="left"><span class="emphasis"><em>Numerical Facilities</em></span></td></tr><tr><td align="left">5.1</td><td align="left">Random number generation</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">5.1.1</td><td align="left">Requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.2</td><td align="left">Header <code class="code">&lt;random&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.3</td><td align="left">Class template <code class="code">variate_generator</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.4</td><td align="left">Random number engine class templates</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.4.1</td><td align="left">Class template <code class="code">linear_congruential</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.4.2</td><td align="left">Class template <code class="code">mersenne_twister</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.4.3</td><td align="left">Class template <code class="code">subtract_with_carry</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.4.4</td><td align="left">Class template <code class="code">subtract_with_carry_01</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.4.5</td><td align="left">Class template <code class="code">discard_block</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.4.6</td><td align="left">Class template <code class="code">xor_combine</code></td><td align="left">Y</td><td align="left">operator()() per N2079</td></tr><tr><td align="left">5.1.5</td><td align="left">Engines with predefined parameters</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.6</td><td align="left">Class <code class="code">random_device</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.7</td><td align="left">Random distribution class templates</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.7.1</td><td align="left">Class template <code class="code">uniform_int</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.7.2</td><td align="left">Class <code class="code">bernoulli_distribution</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.7.3</td><td align="left">Class template <code class="code">geometric_distribution</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.7.4</td><td align="left">Class template <code class="code">poisson_distribution</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.7.5</td><td align="left">Class template <code class="code">binomial_distribution</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.7.6</td><td align="left">Class template <code class="code">uniform_real</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.7.7</td><td align="left">Class template <code class="code">exponential_distribution</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.7.8</td><td align="left">Class template <code class="code">normal_distribution</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.1.7.9</td><td align="left">Class template <code class="code">gamma_distribution</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2</td><td align="left">Mathematical special functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1</td><td align="left">Additions to header <code class="code">&lt;cmath&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.1</td><td align="left">associated Laguerre polynomials</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.2</td><td align="left">associated Legendre functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.3</td><td align="left">beta function</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.4</td><td align="left">(complete) elliptic integral of the first kind</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.5</td><td align="left">(complete) elliptic integral of the second kind</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.6</td><td align="left">(complete) elliptic integral of the third kind</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.7</td><td align="left">confluent hypergeometric functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.8</td><td align="left">regular modified cylindrical Bessel functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.9</td><td align="left">cylindrical Bessel functions (of the first kind)</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.10</td><td align="left">irregular modified cylindrical Bessel functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.11</td><td align="left">cylindrical Neumann functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.12</td><td align="left">(incomplete) elliptic integral of the first kind</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.13</td><td align="left">(incomplete) elliptic integral of the second kind</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.14</td><td align="left">(incomplete) elliptic integral of the third kind</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.15</td><td align="left">exponential integral</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.16</td><td align="left">Hermite polynomials</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.17</td><td align="left">hypergeometric functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.18</td><td align="left">Laguerre polynomials</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.19</td><td align="left">Legendre polynomials</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.20</td><td align="left">Riemann zeta function</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.21</td><td align="left">spherical Bessel functions (of the first kind)</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.22</td><td align="left">spherical associated Legendre functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.1.23</td><td align="left">spherical Neumann functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">5.2.2</td><td align="left">Additions to header <code class="code">&lt;math.h&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left"><span class="emphasis"><em>6</em></span></td><td colspan="3" align="left"><span class="emphasis"><em>Containers</em></span></td></tr><tr><td align="left">6.1</td><td align="left">Tuple types</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.1.1</td><td align="left">Header <code class="code">&lt;tuple&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.1.2</td><td align="left">Additions to header <code class="code">&lt;utility&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.1.3</td><td align="left">Class template <code class="code">tuple</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.1.3.1</td><td align="left">Construction</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.1.3.2</td><td align="left">Tuple creation functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.1.3.3</td><td align="left">Tuple helper classes</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.1.3.4</td><td align="left">Element access</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.1.3.5</td><td align="left">Relational operators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.1.4</td><td align="left">Pairs</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.2</td><td align="left">Fixed size array</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.2.1</td><td align="left">Header <code class="code">&lt;array&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.2.2</td><td align="left">Class template <code class="code">array</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.2.2.1</td><td align="left"><code class="code">array</code> constructors, copy, and assignment</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.2.2.2</td><td align="left"><code class="code">array</code> specialized algorithms</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.2.2.3</td><td align="left"><code class="code">array</code> size</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.2.2.4</td><td align="left">Zero sized <code class="code">array</code>s</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.2.2.5</td><td align="left">Tuple interface to class template <code class="code">array</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3</td><td align="left">Unordered associative containers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.1</td><td align="left">Unordered associative container requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.1.1</td><td align="left">Exception safety guarantees</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.2</td><td align="left">Additions to header <code class="code">&lt;functional&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.3</td><td align="left">Class template <code class="code">hash</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4</td><td align="left">Unordered associative container classes</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.1</td><td align="left">Header <code class="code">&lt;unordered_set&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.2</td><td align="left">Header <code class="code">&lt;unordered_map&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.3</td><td align="left">Class template <code class="code">unordered_set</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.3.1</td><td align="left"><code class="code">unordered_set</code> constructors</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.3.2</td><td align="left"><code class="code">unordered_set</code> swap</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.4</td><td align="left">Class template <code class="code">unordered_map</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.4.1</td><td align="left"><code class="code">unordered_map</code> constructors</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.4.2</td><td align="left"><code class="code">unordered_map</code> element access</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.4.3</td><td align="left"><code class="code">unordered_map</code> swap</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.5</td><td align="left">Class template <code class="code">unordered_multiset<code class="code"></code></code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.5.1</td><td align="left"><code class="code">unordered_multiset</code> constructors</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.5.2</td><td align="left"><code class="code">unordered_multiset</code> swap</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.6</td><td align="left">Class template <code class="code">unordered_multimap</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.6.1</td><td align="left"><code class="code">unordered_multimap</code> constructors</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">6.3.4.6.2</td><td align="left"><code class="code">unordered_multimap</code> swap</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left"><span class="emphasis"><em>7</em></span></td><td colspan="3" align="left"><span class="emphasis"><em>Regular Expressions</em></span></td></tr><tr bgcolor="#C8B0B0"><td align="left">7.1</td><td align="left">Definitions</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.2</td><td align="left">Requirements</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.3</td><td align="left">Regular expressions summary</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.4</td><td align="left">Header <code class="code">&lt;regex&gt;</code> synopsis</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.5</td><td align="left">Namespace <code class="code">tr1::regex_constants</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.5.1</td><td align="left">Bitmask Type <code class="code">syntax_option_type</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.5.2</td><td align="left">Bitmask Type <code class="code">regex_constants::match_flag_type</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.5.3</td><td align="left">Implementation defined <code class="code">error_type</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.6</td><td align="left">Class <code class="code">regex_error</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.7</td><td align="left">Class template <code class="code">regex_traits</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.8</td><td align="left">Class template <code class="code">basic_regex</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.8.1</td><td align="left"><code class="code">basic_regex</code> constants</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.8.2</td><td align="left"><code class="code">basic_regex</code> constructors</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.8.3</td><td align="left"><code class="code">basic_regex</code> assign</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.8.4</td><td align="left"><code class="code">basic_regex</code> constant operations</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.8.5</td><td align="left"><code class="code">basic_regex</code> locale</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.8.6</td><td align="left"><code class="code">basic_regex</code> swap</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.8.7</td><td align="left"><code class="code">basic_regex</code> non-member functions</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.8.7.1</td><td align="left"><code class="code">basic_regex</code> non-member swap</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.9</td><td align="left">Class template <code class="code">sub_match</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.9.1</td><td align="left"><code class="code">sub_match</code> members</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.9.2</td><td align="left"><code class="code">sub_match</code> non-member operators</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.10</td><td align="left">Class template <code class="code">match_results</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.10.1</td><td align="left"><code class="code">match_results</code> constructors</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.10.2</td><td align="left"><code class="code">match_results</code> size</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.10.3</td><td align="left"><code class="code">match_results</code> element access</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.10.4</td><td align="left"><code class="code">match_results</code> formatting</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.10.5</td><td align="left"><code class="code">match_results</code> allocator</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.10.6</td><td align="left"><code class="code">match_results</code> swap</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.11</td><td align="left">Regular expression algorithms</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.11.1</td><td align="left">exceptions</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.11.2</td><td align="left"><code class="code">regex_match</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.11.3</td><td align="left"><code class="code">regex_search</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.11.4</td><td align="left"><code class="code">regex_replace</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.12</td><td align="left">Regular expression Iterators</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.12.1</td><td align="left">Class template <code class="code">regex_iterator</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.12.1.1</td><td align="left"><code class="code">regex_iterator</code> constructors</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.12.1.2</td><td align="left"><code class="code">regex_iterator</code> comparisons</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.12.1.3</td><td align="left"><code class="code">regex_iterator</code> dereference</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.12.1.4</td><td align="left"><code class="code">regex_iterator</code> increment</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.12.2</td><td align="left">Class template <code class="code">regex_token_iterator</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.12.2.1</td><td align="left"><code class="code">regex_token_iterator</code> constructors</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.12.2.2</td><td align="left"><code class="code">regex_token_iterator</code> comparisons</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.12.2.3</td><td align="left"><code class="code">regex_token_iterator</code> dereference</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.12.2.4</td><td align="left"><code class="code">regex_token_iterator</code> increment</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">7.13</td><td align="left">Modified ECMAScript regular expression grammar</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left"><span class="emphasis"><em>8</em></span></td><td colspan="3" align="left"><span class="emphasis"><em>C Compatibility</em></span></td></tr><tr><td align="left">8.1</td><td align="left">Additions to header <code class="code">&lt;complex&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.1.1</td><td align="left">Synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.1.2</td><td align="left">Function <code class="code">acos</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.1.3</td><td align="left">Function <code class="code">asin</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.1.4</td><td align="left">Function <code class="code">atan</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.1.5</td><td align="left">Function <code class="code">acosh</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.1.6</td><td align="left">Function <code class="code">asinh</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.1.7</td><td align="left">Function <code class="code">atanh</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.1.8</td><td align="left">Function <code class="code">fabs</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.1.9</td><td align="left">Additional Overloads</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">8.2</td><td align="left">Header <code class="code">&lt;ccomplex&gt;</code></td><td align="left">N</td><td align="left">DR 551</td></tr><tr bgcolor="#C8B0B0"><td align="left">8.3</td><td align="left">Header <code class="code">&lt;complex.h&gt;</code></td><td align="left">N</td><td align="left">DR 551</td></tr><tr><td align="left">8.4</td><td align="left">Additions to header <code class="code">&lt;cctype&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.4.1</td><td align="left">Synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.4.2</td><td align="left">Function <code class="code">isblank</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.5</td><td align="left">Additions to header <code class="code">&lt;ctype.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.6</td><td align="left">Header <code class="code">&lt;cfenv&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.6.1</td><td align="left">Synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.6.2</td><td align="left">Definitions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.7</td><td align="left">Header <code class="code">&lt;fenv.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.8</td><td align="left">Additions to header <code class="code">&lt;cfloat&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.9</td><td align="left">Additions to header <code class="code">&lt;float.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">8.10</td><td align="left">Additions to header <code class="code">&lt;ios&gt;</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">8.10.1</td><td align="left">Synopsis</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">8.10.2</td><td align="left">Function <code class="code">hexfloat</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">8.11</td><td align="left">Header <code class="code">&lt;cinttypes&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.11.1</td><td align="left">Synopsis</td><td align="left">Y</td><td align="left">DR 557</td></tr><tr><td align="left">8.11.2</td><td align="left">Definitions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.12</td><td align="left">Header <code class="code">&lt;inttypes.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.13</td><td align="left">Additions to header <code class="code">&lt;climits&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.14</td><td align="left">Additions to header <code class="code">&lt;limits.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">8.15</td><td align="left">Additions to header <code class="code">&lt;locale&gt;</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">8.16</td><td align="left">Additions to header <code class="code">&lt;cmath&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.16.1</td><td align="left">Synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.16.2</td><td align="left">Definitions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.16.3</td><td align="left">Function template definitions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.16.4</td><td align="left">Additional overloads</td><td align="left">Y</td><td align="left">DR 568; DR 550</td></tr><tr><td align="left">8.17</td><td align="left">Additions to header <code class="code">&lt;math.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.18</td><td align="left">Additions to header <code class="code">&lt;cstdarg&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.19</td><td align="left">Additions to header <code class="code">&lt;stdarg.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.20</td><td align="left">The header <code class="code">&lt;cstdbool&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.21</td><td align="left">The header <code class="code">&lt;stdbool.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.22</td><td align="left">The header <code class="code">&lt;cstdint&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.22.1</td><td align="left">Synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.22.2</td><td align="left">Definitions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.23</td><td align="left">The header <code class="code">&lt;stdint.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.24</td><td align="left">Additions to header <code class="code">&lt;cstdio&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.24.1</td><td align="left">Synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.24.2</td><td align="left">Definitions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.24.3</td><td align="left">Additional format specifiers</td><td align="left">Y</td><td align="left">C library dependency</td></tr><tr><td align="left">8.24.4</td><td align="left">Additions to header <code class="code">&lt;stdio.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.25</td><td align="left">Additions to header <code class="code">&lt;cstdlib&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.25.1</td><td align="left">Synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.25.2</td><td align="left">Definitions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.25.3</td><td align="left">Function <code class="code">abs</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.25.4</td><td align="left">Function <code class="code">div</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.26</td><td align="left">Additions to header <code class="code">&lt;stdlib.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.27</td><td align="left">Header <code class="code">&lt;ctgmath&gt;</code></td><td align="left">Y</td><td align="left">DR 551</td></tr><tr><td align="left">8.28</td><td align="left">Header <code class="code">&lt;tgmath.h&gt;</code></td><td align="left">Y</td><td align="left">DR 551</td></tr><tr><td align="left">8.29</td><td align="left">Additions to header <code class="code">&lt;ctime&gt;</code></td><td align="left">Y</td><td align="left">C library dependency</td></tr><tr><td align="left">8.30</td><td align="left">Additions to header <code class="code">&lt;cwchar&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.30.1</td><td align="left">Synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.30.2</td><td align="left">Definitions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.30.3</td><td align="left">Additional wide format specifiers</td><td align="left">Y</td><td align="left">C library dependency</td></tr><tr><td align="left">8.31</td><td align="left">Additions to header <code class="code">&lt;wchar.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.32</td><td align="left">Additions to header <code class="code">&lt;cwctype&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.32.1</td><td align="left">Synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.32.2</td><td align="left">Function <code class="code">iswblank</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">8.33</td><td align="left">Additions to header <code class="code">&lt;wctype.h&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr></tbody></table></div></div><br class="table-break" /></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.standard.200x"></a>C++ 200x</h3></div></div></div><p>
-This table is based on the table of contents of ISO/IEC
-Doc No: N2857=09-0047 Date: 2009-03-23
-Working Draft, Standard for Programming Language C++
-</p><p>
-In this implementation <code class="literal">-std=gnu++0x</code> or
-<code class="literal">-std=c++0x</code> flags must be used to enable language and
-library features. The pre-defined symbol
-<code class="constant">__GXX_EXPERIMENTAL_CXX0X__</code> is used to check for the
-presence of the required flag.
-</p><p>
-This page describes the C++0x support in mainline GCC SVN, not in any
-particular release.
-</p><div class="table"><a id="id399999"></a><p class="title"><b>Table 1.3. C++ 200x Implementation Status</b></p><div class="table-contents"><table summary="C++ 200x Implementation Status" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><thead><tr><th align="left">Section</th><th align="left">Description</th><th align="left">Status</th><th align="left">Comments</th></tr></thead><tbody><tr><td align="left">
- <span class="emphasis"><em>18</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Language support</em></span>
- </td></tr><tr><td align="left">18.1</td><td align="left">General</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">18.2</td><td align="left">Types</td><td align="left">Partial</td><td align="left">Missing offsetof, max_align_t, nullptr_t</td></tr><tr><td align="left">18.3</td><td align="left">Implementation properties</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">18.3.1</td><td align="left">Numeric Limits</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">18.3.1.1</td><td align="left">Class template <code class="code">numeric_limits</code></td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">18.3.1.2</td><td align="left"><code class="code">numeric_limits</code> members</td><td align="left">Partial</td><td align="left">Missing constexpr</td></tr><tr bgcolor="#C8B0B0"><td align="left">18.3.1.3</td><td align="left"><code class="code">float_round_style</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">18.3.1.4</td><td align="left"><code class="code">float_denorm_style</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">18.3.1.5</td><td align="left"><code class="code">numeric_limits</code> specializations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.3.2</td><td align="left">C Library</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.4</td><td align="left">Integer types</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">18.4.1</td><td align="left">Header <code class="code">&lt;cstdint&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">18.4.2</td><td align="left">The header <code class="code">&lt;stdint.h&gt;</code></td><td align="left">Partial</td><td align="left">May use configure-generated stdint.h via GCC_HEADER_STDINT</td></tr><tr bgcolor="#B0B0B0"><td align="left">18.5</td><td align="left">Start and termination</td><td align="left">Partial</td><td align="left">Missing quick_exit, at_quick_exit</td></tr><tr><td align="left">18.6</td><td align="left">Dynamic memory management</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.7</td><td align="left">Type identification</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">18.7.1</td><td align="left">Class type_info</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">18.7.2</td><td align="left">Class type_index</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">18.7.3</td><td align="left">Class bad_cast</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.7.4</td><td align="left">Class bad_typeid</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.8</td><td align="left">Exception handling</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">18.8.1</td><td align="left">Class exception</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.8.2</td><td align="left">Violation exception-specifications</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.8.3</td><td align="left">Abnormal termination</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.8.4</td><td align="left"><code class="code">uncaught_exception</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.8.5</td><td align="left">Propagation</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">18.8.6</td><td align="left">Class <code class="code">nested_exception</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">18.9</td><td align="left">Initializer lists</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">18.9.1</td><td align="left">Initializer list constructors</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">18.9.2</td><td align="left">Initializer list access</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">18.9.3</td><td align="left">Initializer list concept maps</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">18.10</td><td align="left">Other runtime support</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>19</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Diagnostics</em></span>
- </td></tr><tr><td align="left">19.1</td><td align="left">General</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">19.2</td><td align="left">Exception classes</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">19.3</td><td align="left">Assertions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">19.4</td><td align="left">Error numbers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">19.5</td><td align="left">System error support</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">19.5.1</td><td align="left">Class <code class="code">error_category</code></td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">19.5.2</td><td align="left">Class <code class="code">error_code</code></td><td align="left">Partial</td><td align="left">Missing concept ErrorCodeEnum</td></tr><tr bgcolor="#B0B0B0"><td align="left">19.5.3</td><td align="left">Class <code class="code">error_condition</code></td><td align="left">Partial</td><td align="left">Missing concept ErrorConditionEnum</td></tr><tr><td align="left">19.5.4</td><td align="left">Comparison operators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">19.5.5</td><td align="left">Class <code class="code">system_error</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>20</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>General utilities</em></span>
- </td></tr><tr bgcolor="#B0B0B0"><td align="left">20.1</td><td align="left">General</td><td align="left">Partial</td><td align="left">Missing all concepts</td></tr><tr bgcolor="#C8B0B0"><td align="left">20.2</td><td align="left">Concepts</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">20.3</td><td align="left">Utility components</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.3.1</td><td align="left">Operators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.3.2</td><td align="left"><code class="code">forward</code> and <code class="code">move</code> helpers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.3.3</td><td align="left"><code class="code">pair</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.3.4</td><td align="left">tuple-like access to <code class="code">pair</code></td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.3.5</td><td align="left">Range concept maps for <code class="code">pair</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">20.3.6</td><td align="left">Class template <code class="code">bitset</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4</td><td align="left">Compile-time rational arithmetic</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.4.1</td><td align="left">Class template <code class="code">ratio</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4.2</td><td align="left">Arithmetic on <code class="code">ratio</code> types</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4.3</td><td align="left">Comparison of <code class="code">ratio</code> types</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.4.4</td><td align="left">SI types</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.5</td><td align="left">Tuples</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.5.1</td><td align="left">General</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">20.5.2</td><td align="left">Class template <code class="code">tuple</code></td><td align="left">Partial</td><td align="left">Missing range concept maps</td></tr><tr><td align="left">20.6</td><td align="left">Metaprogramming and type traits</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.6.1</td><td align="left">Requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">20.6.2</td><td align="left">Header <code class="code">&lt;type_traits&gt;</code> synopsis</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.6.3</td><td align="left">Helper classes</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.6.4</td><td align="left">Unary Type Traits</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.6.4.1</td><td align="left">Primary type categories</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.6.4.2</td><td align="left">Composite type traits</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">20.6.4.3</td><td align="left">Type properties</td><td align="left">Partial</td><td align="left">Missing is_system_layout</td></tr><tr><td align="left">20.6.5</td><td align="left">Relationships between types</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.6.6</td><td align="left">Transformations between types</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.6.6.1</td><td align="left">Const-volatile modifications</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.6.6.2</td><td align="left">Reference modifications</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.6.6.3</td><td align="left">Sign modifications</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.6.6.4</td><td align="left">Array modifications</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.6.6.5</td><td align="left">Pointer modifications</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">20.6.7</td><td align="left">Other transformations</td><td align="left">Partial</td><td align="left">Missing decay</td></tr><tr><td align="left">20.7</td><td align="left">Function objects</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.7.1</td><td align="left">Definitions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.3</td><td align="left">Base</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.4</td><td align="left">Function object return types</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.5</td><td align="left">Class template <code class="code">reference_wrapper</code></td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.7.6</td><td align="left">Identity operation</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">20.7.7</td><td align="left">Arithmetic operation</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.8</td><td align="left">Comparisons</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.9</td><td align="left">Logical operations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.10</td><td align="left">Bitwise operations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.11</td><td align="left">Negators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.12</td><td align="left">Template <code class="code">function</code> and function template <code class="code">bind</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.13</td><td align="left">Adaptors for pointers to functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.14</td><td align="left">Adaptors for pointers to members</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.15</td><td align="left">Function template <code class="code">mem_fn</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.16</td><td align="left">Polymorphic function wrappers</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.7.16.1</td><td align="left">Class <code class="code">bad_function_call</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.16.2</td><td align="left">Class template <code class="code">function</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.7.17</td><td align="left">Class template <code class="code">hash</code></td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.7.18</td><td align="left">Class template <code class="code">reference_closure</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">20.8</td><td align="left">Memory</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.01</td><td align="left">Allocator argument tag</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">20.8.02</td><td align="left">Allocators</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.8.02.1</td><td align="left">General</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.02.2</td><td align="left">Allocator concept</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.02.3</td><td align="left">Support for legacy allocators</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.02.4</td><td align="left">Allocator and Legacy Allocator members</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.03</td><td align="left">Allocator-related element concepts</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.04</td><td align="left">Allocator propagation traits</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.05</td><td align="left">Allocator propagation map</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">20.8.06</td><td align="left">The default allocator</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.8.07</td><td align="left">Scoped allocator adaptor</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.07.1</td><td align="left"><code class="code">scoped_allocator_adaptor_base</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.07.2</td><td align="left"><code class="code">scoped_allocator_adaptor constructors</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.07.3</td><td align="left"><code class="code">scoped_allocator_adaptor2</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.07.3</td><td align="left">scoped_allocator_adaptor members</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.07.4</td><td align="left"><code class="code">scoped_allocator_adaptor globals</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">20.8.08</td><td align="left">Raw storage iterator</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.8.09</td><td align="left">Temporary buffers</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.10</td><td align="left"><code class="code">construct_element</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">20.8.11</td><td align="left">Specialized algorithms</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.11.1</td><td align="left"><code class="code">addressof</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">20.8.11.2</td><td align="left"><code class="code">uninitialized_copy</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.8.11.3</td><td align="left"><code class="code">uninitialized_fill</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.8.11.4</td><td align="left"><code class="code">uninitialized_fill_n</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.8.12</td><td align="left">Class template <code class="code">unique_ptr</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.8.13</td><td align="left">Smart pointers</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.8.13.1</td><td align="left">Class <code class="code">bad_weak_ptr</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.8.13.2</td><td align="left">Class template <code class="code">shared_ptr</code></td><td align="left">Y</td><td align="left">
- <p>
- Uses code from
- <a class="ulink" href="http://www.boost.org/libs/smart_ptr/shared_ptr.htm" target="_top">boost::shared_ptr</a>.
- </p>
- </td></tr><tr><td align="left">20.8.13.3</td><td align="left">Class template <code class="code">weak_ptr</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.8.13.4</td><td align="left">Class template <code class="code">owner_less</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.8.13.5</td><td align="left">Class template <code class="code">emable_shared_from_this</code></td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">20.8.13.6</td><td align="left"><code class="code">shared_ptr</code> atomic access</td><td align="left">Partial</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">20.8.13.7</td><td align="left">Pointer safety</td><td align="left">Partial</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">20.8.14</td><td align="left">Align</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">20.8.15</td><td align="left">C library</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.9</td><td align="left">Time utilities</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.9.1</td><td align="left">Clock requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.9.2</td><td align="left">Time-related traits</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.9.2.1</td><td align="left"><code class="code">treat_as_floating_point</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.9.2.2</td><td align="left"><code class="code">duration_values</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.9.2.3</td><td align="left">Specializations of <code class="code">common_type</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.9.3</td><td align="left">Class template <code class="code">duration</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.9.4</td><td align="left">Class template <code class="code">time_point</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.9.5</td><td align="left">Clocks</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">20.9.5.1</td><td align="left">Class <code class="code">system_clock</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.9.5.2</td><td align="left">Class <code class="code">monotonic_clock</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.9.5.3</td><td align="left">Class <code class="code">high_resolution_clock</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">20.10</td><td align="left">Date and time functions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>21</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Strings</em></span>
- </td></tr><tr><td align="left">21.1</td><td align="left">General</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.2</td><td align="left">Character traits</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">21.2.1</td><td align="left">Character traits requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.2.2</td><td align="left">traits typedef</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.2.3</td><td align="left"><code class="code">char_traits</code> specializations</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">21.2.3.1</td><td align="left">struct <code class="code">char_traits&lt;char&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.2.3.2</td><td align="left">struct <code class="code">char_traits&lt;char16_t&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.2.3.3</td><td align="left">struct <code class="code">char_traits&lt;char32_t&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.2.3.4</td><td align="left">struct <code class="code">char_traits&lt;wchar_t&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.3</td><td align="left">String classes</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.4</td><td align="left">Class template <code class="code">basic_string</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.5</td><td align="left">Numeric Conversions</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">21.6</td><td align="left">Null-terminated sequence utilities</td><td align="left">Y</td><td align="left">C library dependency</td></tr><tr><td align="left">
- <span class="emphasis"><em>22</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Localization</em></span>
- </td></tr><tr><td align="left">22.1</td><td align="left">General</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.2</td><td align="left">Header <code class="code">&lt;locale&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.3</td><td align="left">Locales</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.3.1</td><td align="left">Class <code class="code">locale</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.3.2</td><td align="left"><code class="code">locale</code> globals</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.3.3</td><td align="left">Convenience interfaces</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.3.3.1</td><td align="left">Character classification</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.3.3.2</td><td align="left">Conversions</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.3.3.2.1</td><td align="left">Character</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">22.3.3.2.2</td><td align="left">String</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">22.3.3.2.3</td><td align="left">Buffer</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">22.4</td><td align="left">Standard locale categories</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.4.1</td><td align="left"><code class="code">ctype</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.2</td><td align="left">Numeric</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.4.2.1</td><td align="left"><code class="code">num_get</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.2.2</td><td align="left"><code class="code">num_put</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.3</td><td align="left"><code class="code">num_punct</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.4</td><td align="left"><code class="code">collate</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.5</td><td align="left">Time</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.4.5.1</td><td align="left"><code class="code">time_get</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.5.2</td><td align="left"><code class="code">time_get_byname</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.5.3</td><td align="left"><code class="code">time_put</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.5.3</td><td align="left"><code class="code">time_put_byname</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.6</td><td align="left">Monetary</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">22.4.6.1</td><td align="left"><code class="code">money_get</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.6.2</td><td align="left"><code class="code">money_put</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.6.3</td><td align="left"><code class="code">money_punct</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.6.4</td><td align="left"><code class="code">money_punct_byname</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.7</td><td align="left"><code class="code">messages</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">22.4.8</td><td align="left">Program-defined facets</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">22.5</td><td align="left">Standard code conversion facets</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">22.6</td><td align="left">C Library Locales</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>23</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Containers</em></span>
- </td></tr><tr bgcolor="#B0B0B0"><td align="left">23.1</td><td align="left">General</td><td align="left">Partial</td><td align="left">Missing concepts</td></tr><tr><td align="left">23.2</td><td align="left">Container requirements</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">23.2.1</td><td align="left">General requirements</td><td align="left">Partial</td><td align="left">Missing construct_element</td></tr><tr><td align="left">23.2.2</td><td align="left">Data races</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3</td><td align="left">Sequence containers</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">23.3.1</td><td align="left">Class template <code class="code">array</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3.2</td><td align="left">Class template <code class="code">deque</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3.3</td><td align="left">Class template <code class="code">forward_list</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3.4</td><td align="left">Class template <code class="code">list</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3.5</td><td align="left">Adaptors</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">23.3.5.1</td><td align="left">Class template <code class="code">queue</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3.5.2</td><td align="left">Class template <code class="code">priority_queue</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3.5.3</td><td align="left">Class template <code class="code">stack</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3.6</td><td align="left">Class template <code class="code">vector</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.3.7</td><td align="left">Class <code class="code">vector&lt;bool&gt;</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.4</td><td align="left">Associative containers</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">23.4.1</td><td align="left">Class template <code class="code">map</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.4.2</td><td align="left">Class template <code class="code">multimap</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.4.3</td><td align="left">Class template <code class="code">set</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.4.4</td><td align="left">Class template <code class="code">multiset</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.5</td><td align="left">Unordered associative containers</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">23.5.1</td><td align="left">Class template <code class="code">unordered_map</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.5.2</td><td align="left">Class template <code class="code">unordered_multimap</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.5.3</td><td align="left">Class template <code class="code">unordered_set</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">23.5.4</td><td align="left">Class template <code class="code">unordered_multiset</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>24</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Iterators</em></span>
- </td></tr><tr bgcolor="#B0B0B0"><td align="left">24.1</td><td align="left">General</td><td align="left">Partial</td><td align="left">Missing concepts</td></tr><tr bgcolor="#C8B0B0"><td align="left">24.2</td><td align="left">Iterator concepts</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">24.3</td><td align="left">Header <code class="code">&lt;iterator&gt;</code> synopsis</td><td align="left">Partial</td><td align="left">Missing concepts</td></tr><tr><td align="left">24.4</td><td align="left">Iterator operations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.5</td><td align="left">Predefined iterators and Iterator adaptors</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">24.5.1</td><td align="left">Reverse iterators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.5.2</td><td align="left">Insert iterators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.5.3</td><td align="left">Move iterators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.6</td><td align="left">Stream iterators</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">24.6.1</td><td align="left">Class template <code class="code">istream_iterator</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.6.2</td><td align="left">Class template <code class="code">ostream_iterator</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.6.3</td><td align="left">Class template <code class="code">istreambuf_iterator</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.6.4</td><td align="left">Class template <code class="code">ostreambuf_iterator</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.7</td><td align="left">Insert iterators</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">24.7.1</td><td align="left">Class template <code class="code">back_insert_iterator</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.7.3</td><td align="left">Class template <code class="code">front_insert_iterator</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">24.7.5</td><td align="left">Class template <code class="code">insert_iterator</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>25</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Algorithms</em></span>
- </td></tr><tr bgcolor="#B0B0B0"><td align="left">25.1</td><td align="left">General</td><td align="left">Partial</td><td align="left">Missing concepts</td></tr><tr><td align="left">25.2</td><td align="left">Header <code class="code">&lt;algorithm&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">25.3</td><td align="left">Non-modifying sequence operations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">25.4</td><td align="left">Mutating sequence operations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">25.5</td><td align="left">Sorting and related operations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">25.6</td><td align="left">C library algorithms</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>26</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Numerics</em></span>
- </td></tr><tr><td align="left">26.1</td><td align="left">General</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.2</td><td align="left">Numeric type requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.3</td><td align="left">The floating-point environment</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.4</td><td align="left">Complex numbers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.5</td><td align="left">Random number generation</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">26.5.1</td><td align="left">Header <code class="code">&lt;random&gt;</code> synopsis</td><td align="left">Partial</td><td align="left">Missing concepts, based on TR1</td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.2</td><td align="left">Concepts and related requirements</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">26.5.3</td><td align="left">Random number engines</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.3.1</td><td align="left">Class template <code class="code">linear_congruential_engine</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.3.2</td><td align="left">Class template <code class="code">mersenne_twister_engine</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.3.3</td><td align="left">Class template <code class="code">subtract_with_carry_engine</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">26.5.4</td><td align="left">Random number engine adaptors</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.4.1</td><td align="left">Class template <code class="code">discard_block_engine</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.4.2</td><td align="left">Class template <code class="code">independent_bits_engine</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.4.3</td><td align="left">Class template <code class="code">shuffle_order_engine</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.5</td><td align="left">Engines and engine adaptors with predefined parameters</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.6</td><td align="left">Class <code class="code">random_device</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">26.5.7</td><td align="left">Utilities</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.7.1</td><td align="left">Class <code class="code">seed_seq</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.7.2</td><td align="left">Function template generate_canonical</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">26.5.8</td><td align="left">Random number distributions</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">26.5.8.1</td><td align="left">Uniform distributions</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.1.1</td><td align="left">Class template <code class="code">uniform_int_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.1.2</td><td align="left">Class template <code class="code">uniform_real_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">26.5.8.2</td><td align="left">Bernoulli distributions</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.2.1</td><td align="left">Class <code class="code">bernoulli_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.2.2</td><td align="left">Class template <code class="code">binomial_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.2.3</td><td align="left">Class template <code class="code">geometric_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.2.4</td><td align="left">Class template <code class="code">negative_binomial_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">26.5.8.3</td><td align="left">Poisson distributions</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.3.1</td><td align="left">Class template <code class="code">poisson_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.3.2</td><td align="left">Class template <code class="code">exponential_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.3.3</td><td align="left">Class template <code class="code">gamma_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.3.4</td><td align="left">Class template <code class="code">weibull_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.3.5</td><td align="left">Class template <code class="code">extreme_value_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">26.5.8.4</td><td align="left">Normal distributions</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.4.1</td><td align="left">Class template <code class="code">normal_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.4.2</td><td align="left">Class template <code class="code">lognormal_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.4.3</td><td align="left">Class template <code class="code">chi_squared_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.4.4</td><td align="left">Class template <code class="code">cauchy_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.4.5</td><td align="left">Class template <code class="code">fisher_f_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.4.6</td><td align="left">Class template <code class="code">student_t_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">26.5.8.5</td><td align="left">Sampling distributions</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.5.1</td><td align="left">Class template <code class="code">discrete_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.5.2</td><td align="left">Class template <code class="code">piecewise_constant_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">26.5.8.5.3</td><td align="left">Class template <code class="code">piecewise_linear_distribution</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">26.6</td><td align="left">Numeric arrays</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">26.6.1</td><td align="left">Header <code class="code">&lt;valarray&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.6.2</td><td align="left">Class template <code class="code">valarray</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.6.3</td><td align="left"><code class="code">valarray</code> non-member operations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.6.4</td><td align="left">Class <code class="code">slice</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.6.5</td><td align="left">Class template <code class="code">slice_array</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.6.6</td><td align="left">Class <code class="code">gslice</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.6.7</td><td align="left">Class template <code class="code">gslice_array</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.6.8</td><td align="left">Class template <code class="code">mask_array</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.6.9</td><td align="left">Class template <code class="code">indirect_array</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.7</td><td align="left">Generalized numeric operations</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">26.7.1</td><td align="left"><code class="code">accumulate</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.7.2</td><td align="left"><code class="code">inner_product</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.7.3</td><td align="left"><code class="code">partial_sum</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.7.4</td><td align="left"><code class="code">adjacent_difference</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.7.5</td><td align="left">iota</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">26.8</td><td align="left">C Library</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>27</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Input/output</em></span>
- </td></tr><tr><td align="left">27.1</td><td align="left">General</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.2</td><td align="left">Requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.2.1</td><td align="left">Imbue limitations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.2.2</td><td align="left">Positioning type limitations</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">27.2.3</td><td align="left">Thread safety</td><td align="left">Partial</td><td align="left"> </td></tr><tr><td align="left">27.3</td><td align="left">Forward declarations</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.4</td><td align="left">Standard iostream objects</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.4.1</td><td align="left">Narrow stream objects</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.4.2</td><td align="left">Wide stream objects</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.5</td><td align="left">Iostreams base classes</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.6</td><td align="left">Stream buffers</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.7</td><td align="left">Formatting and manipulators</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.8</td><td align="left">String-based streams</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">27.9</td><td align="left">File-based streams</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>28</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Regular expressions</em></span>
- </td></tr><tr bgcolor="#C8B0B0"><td align="left">28.01</td><td align="left">General</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">28.02</td><td align="left">Definitions</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">28.03</td><td align="left">Requirements</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">28.04</td><td align="left">Regular expressions summary</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">28.05</td><td align="left">Header <code class="code">&lt;regex&gt;</code> synopsis</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">28.06</td><td align="left">Namespace <code class="code">std::regex_constants</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">28.07</td><td align="left">Class <code class="code">regex_error</code></td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">28.08</td><td align="left">Class template <code class="code">regex_traits</code></td><td align="left">Partial</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">28.09</td><td align="left">Class template <code class="code">basic_regex</code></td><td align="left">Partial</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">28.10</td><td align="left">Class template <code class="code">sub_match</code></td><td align="left">Partial</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">28.11</td><td align="left">Class template <code class="code">match_results</code></td><td align="left">Partial</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">28.12</td><td align="left">Regular expression algorithms</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">28.13</td><td align="left">Regular expression Iterators</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">28.14</td><td align="left">Modified ECMAScript regular expression grammar</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>29</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Atomic operations</em></span>
- </td></tr><tr><td align="left">29.1</td><td align="left">General</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">29.2</td><td align="left">Header <code class="code">&lt;cstdatomic&gt;</code> synopsis</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">29.3</td><td align="left">Order and consistency</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">29.4</td><td align="left">Lock-free property</td><td align="left">Y</td><td align="left">Based on _GLIBCXX_ATOMIC_PROPERTY</td></tr><tr><td align="left">29.5</td><td align="left">Atomic types</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">29.5.1</td><td align="left">Integral types</td><td align="left">Y</td><td align="left">Missing constexpr</td></tr><tr><td align="left">29.5.2</td><td align="left">Address types</td><td align="left">Y</td><td align="left">Missing constexpr</td></tr><tr><td align="left">29.5.3</td><td align="left">Generic types</td><td align="left">Y</td><td align="left">Missing constexpr</td></tr><tr><td align="left">29.6</td><td align="left">Operations on atomic types</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">29.7</td><td align="left">Flag Type and operations</td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">29.8</td><td align="left">Fences</td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>30</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Thread support</em></span>
- </td></tr><tr><td align="left">30.1</td><td align="left">General</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">30.2</td><td align="left">Requirements</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">30.3</td><td align="left">Threads</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">30.3.1</td><td align="left">Class <code class="code">thread</code></td><td align="left">Partial</td><td align="left">Missing futures</td></tr><tr><td align="left">30.3.2</td><td align="left">Namespace <code class="code">this_thread</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">30.4</td><td align="left">Mutual exclusion</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">30.4.1</td><td align="left">Mutex requirements</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">30.4.1.1</td><td align="left">Class <code class="code">mutex</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">30.4.1.2</td><td align="left">Class <code class="code">recursive_mutex</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">30.4.2</td><td align="left">Timed mutex requirements</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">30.4.2.1</td><td align="left">Class <code class="code">timed_mutex</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">30.4.2.2</td><td align="left">Class <code class="code">recursive_timed_mutex</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">30.4.3</td><td align="left">Locks</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">30.4.3.1</td><td align="left">Class template <code class="code">lock_guard</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">30.4.3.2</td><td align="left">Class template <code class="code">unique_lock</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">30.4.4</td><td align="left">Generic locking algorithms</td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">30.4.5</td><td align="left">Call once</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">30.4.5.1</td><td align="left"><code class="code">once_flag</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">30.4.5.2</td><td align="left"><code class="code">call_once</code></td><td align="left">Y</td><td align="left"> </td></tr><tr><td align="left">30.5</td><td align="left">Condition variables</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">30.5.1</td><td align="left">Class <code class="code">condition_variable</code></td><td align="left">Y</td><td align="left"> </td></tr><tr bgcolor="#B0B0B0"><td align="left">30.5.2</td><td align="left">Class <code class="code">condition_variable_any</code></td><td align="left">Partial</td><td align="left"> </td></tr><tr><td align="left">30.6</td><td align="left">Futures</td><td align="left"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">30.6.1</td><td align="left">Overview</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">30.6.2</td><td align="left">Error handling</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">30.6.3</td><td align="left">Class <code class="code">future_error</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">30.6.4</td><td align="left">Class template <code class="code">unique_future</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">30.6.5</td><td align="left">Class template <code class="code">shared_future</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">30.6.6</td><td align="left">Class template <code class="code">promise</code></td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">30.6.7</td><td align="left">Allocator templates</td><td align="left">N</td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">30.6.8</td><td align="left">Class template <code class="code">packaged_task</code></td><td align="left">N</td><td align="left"> </td></tr><tr><td align="left">
- <span class="emphasis"><em>Appendix D</em></span>
- </td><td colspan="3" align="left">
- <span class="emphasis"><em>Compatibility features</em></span>
- </td></tr><tr><td align="left">D.1</td><td align="left">Increment operator with bool operand</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.2</td><td align="left"><code class="code">static</code> keyword</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.3</td><td align="left">Access declarations</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.4</td><td align="left">Implicit conversion from const strings</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.5</td><td align="left">C standard library headers</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.6</td><td align="left">Old iostreams members</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.7</td><td align="left">char* streams</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.8</td><td align="left">Binders</td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.9</td><td align="left"><code class="code">auto_ptr</code></td><td align="left"> </td><td align="left"> </td></tr><tr><td align="left">D.10</td><td align="left">Iterator primitives</td><td align="left"> </td><td align="left"> </td></tr></tbody></table></div></div><br class="table-break" /></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="intro.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="intro.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="license.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part I. 
- Introduction
-
- </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> License</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/streambufs.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/streambufs.html
deleted file mode 100644
index a78c2ab4a..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/streambufs.html
+++ /dev/null
@@ -1,60 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 25. Stream Buffers</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="io.html" title="Part XI.  Input and Output" /><link rel="prev" href="iostream_objects.html" title="Chapter 24. Iostream Objects" /><link rel="next" href="bk01pt11ch25s02.html" title="Buffering" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 25. Stream Buffers</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="iostream_objects.html">Prev</a> </td><th width="60%" align="center">Part XI. 
- Input and Output
-
-</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt11ch25s02.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.io.streambufs"></a>Chapter 25. Stream Buffers</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="streambufs.html#io.streambuf.derived">Derived streambuf Classes</a></span></dt><dt><span class="sect1"><a href="bk01pt11ch25s02.html">Buffering</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="io.streambuf.derived"></a>Derived streambuf Classes</h2></div></div></div><p>
- </p><p>Creating your own stream buffers for I/O can be remarkably easy.
- If you are interested in doing so, we highly recommend two very
- excellent books:
- <a class="ulink" href="http://www.langer.camelot.de/iostreams.html" target="_top">Standard C++
- IOStreams and Locales</a> by Langer and Kreft, ISBN 0-201-18395-1, and
- <a class="ulink" href="http://www.josuttis.com/libbook/" target="_top">The C++ Standard Library</a>
- by Nicolai Josuttis, ISBN 0-201-37926-0. Both are published by
- Addison-Wesley, who isn't paying us a cent for saying that, honest.
- </p><p>Here is a simple example, io/outbuf1, from the Josuttis text. It
- transforms everything sent through it to uppercase. This version
- assumes many things about the nature of the character type being
- used (for more information, read the books or the newsgroups):
- </p><pre class="programlisting">
- #include &lt;iostream&gt;
- #include &lt;streambuf&gt;
- #include &lt;locale&gt;
- #include &lt;cstdio&gt;
-
- class outbuf : public std::streambuf
- {
- protected:
- /* central output function
- * - print characters in uppercase mode
- */
- virtual int_type overflow (int_type c) {
- if (c != EOF) {
- // convert lowercase to uppercase
- c = std::toupper(static_cast&lt;char&gt;(c),getloc());
-
- // and write the character to the standard output
- if (putchar(c) == EOF) {
- return EOF;
- }
- }
- return c;
- }
- };
-
- int main()
- {
- // create special output buffer
- outbuf ob;
- // initialize output stream with that output buffer
- std::ostream out(&amp;ob);
-
- out &lt;&lt; "31 hexadecimal: "
- &lt;&lt; std::hex &lt;&lt; 31 &lt;&lt; std::endl;
- return 0;
- }
- </pre><p>Try it yourself! More examples can be found in 3.1.x code, in
- <code class="code">include/ext/*_filebuf.h</code>, and on
- <a class="ulink" href="http://www.informatik.uni-konstanz.de/~kuehl/c++/iostream/" target="_top">Dietmar
- Kühl's IOStreams page</a>.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="iostream_objects.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="io.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt11ch25s02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 24. Iostream Objects </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Buffering</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/strings.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/strings.html
deleted file mode 100644
index e3b37a9df..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/strings.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part V.  Strings</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="shared_ptr.html" title="shared_ptr" /><link rel="next" href="bk01pt05ch13.html" title="Chapter 13. String Classes" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part V. 
- Strings
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="shared_ptr.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt05ch13.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.strings"></a>Part V. 
- Strings
- <a id="id413088" class="indexterm"></a>
-</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="bk01pt05ch13.html">13. String Classes</a></span></dt><dd><dl><dt><span class="sect1"><a href="bk01pt05ch13.html#strings.string.simple">Simple Transformations</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s02.html">Case Sensitivity</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s03.html">Arbitrary Character Types</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s04.html">Tokenizing</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s05.html">Shrink to Fit</a></span></dt><dt><span class="sect1"><a href="bk01pt05ch13s06.html">CString (MFC)</a></span></dt></dl></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="shared_ptr.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt05ch13.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">shared_ptr </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 13. String Classes</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/stringstreams.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/stringstreams.html
deleted file mode 100644
index ccd6fdd48..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/stringstreams.html
+++ /dev/null
@@ -1,37 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 26. Memory Based Streams</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="io.html" title="Part XI.  Input and Output" /><link rel="prev" href="bk01pt11ch25s02.html" title="Buffering" /><link rel="next" href="fstreams.html" title="Chapter 27. File Based Streams" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 26. Memory Based Streams</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt11ch25s02.html">Prev</a> </td><th width="60%" align="center">Part XI. 
- Input and Output
-
-</th><td width="20%" align="right"> <a accesskey="n" href="fstreams.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.io.memstreams"></a>Chapter 26. Memory Based Streams</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="stringstreams.html#manual.io.memstreams.compat">Compatibility With strstream</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.io.memstreams.compat"></a>Compatibility With strstream</h2></div></div></div><p>
- </p><p>Stringstreams (defined in the header <code class="code">&lt;sstream&gt;</code>)
- are in this author's opinion one of the coolest things since
- sliced time. An example of their use is in the Received Wisdom
- section for Chapter 21 (Strings),
- <a class="ulink" href="../21_strings/howto.html#1.1internal" target="_top"> describing how to
- format strings</a>.
- </p><p>The quick definition is: they are siblings of ifstream and ofstream,
- and they do for <code class="code">std::string</code> what their siblings do for
- files. All that work you put into writing <code class="code">&lt;&lt;</code> and
- <code class="code">&gt;&gt;</code> functions for your classes now pays off
- <span class="emphasis"><em>again!</em></span> Need to format a string before passing the string
- to a function? Send your stuff via <code class="code">&lt;&lt;</code> to an
- ostringstream. You've read a string as input and need to parse it?
- Initialize an istringstream with that string, and then pull pieces
- out of it with <code class="code">&gt;&gt;</code>. Have a stringstream and need to
- get a copy of the string inside? Just call the <code class="code">str()</code>
- member function.
- </p><p>This only works if you've written your
- <code class="code">&lt;&lt;</code>/<code class="code">&gt;&gt;</code> functions correctly, though,
- and correctly means that they take istreams and ostreams as
- parameters, not i<span class="emphasis"><em>f</em></span>streams and o<span class="emphasis"><em>f</em></span>streams. If they
- take the latter, then your I/O operators will work fine with
- file streams, but with nothing else -- including stringstreams.
- </p><p>If you are a user of the strstream classes, you need to update
- your code. You don't have to explicitly append <code class="code">ends</code> to
- terminate the C-style character array, you don't have to mess with
- "freezing" functions, and you don't have to manage the
- memory yourself. The strstreams have been officially deprecated,
- which means that 1) future revisions of the C++ Standard won't
- support them, and 2) if you use them, people will laugh at you.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt11ch25s02.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="io.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="fstreams.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Buffering </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 27. File Based Streams</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/support.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/support.html
deleted file mode 100644
index 101fe77e3..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/support.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part II.  Support</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="debug.html" title="Debugging Support" /><link rel="next" href="bk01pt02pr01.html" title="" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part II. 
- Support
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="debug.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="bk01pt02pr01.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.support"></a>Part II. 
- Support
- <a id="id399385" class="indexterm"></a>
-</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="bk01pt02pr01.html"></a></span></dt><dt><span class="chapter"><a href="fundamental_types.html">4. Types</a></span></dt><dd><dl><dt><span class="sect1"><a href="fundamental_types.html#manual.support.types.fundamental">Fundamental Types</a></span></dt><dt><span class="sect1"><a href="bk01pt02ch04s02.html">Numeric Properties</a></span></dt><dt><span class="sect1"><a href="bk01pt02ch04s03.html">NULL</a></span></dt></dl></dd><dt><span class="chapter"><a href="dynamic_memory.html">5. Dynamic Memory</a></span></dt><dt><span class="chapter"><a href="termination.html">6. Termination</a></span></dt><dd><dl><dt><span class="sect1"><a href="termination.html#support.termination.handlers">Termination Handlers</a></span></dt><dt><span class="sect1"><a href="verbose_termination.html">Verbose Terminate Handler</a></span></dt></dl></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="debug.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="bk01pt02pr01.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Debugging Support </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/termination.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/termination.html
deleted file mode 100644
index 30dafcd0f..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/termination.html
+++ /dev/null
@@ -1,48 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 6. Termination</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="support.html" title="Part II.  Support" /><link rel="prev" href="dynamic_memory.html" title="Chapter 5. Dynamic Memory" /><link rel="next" href="verbose_termination.html" title="Verbose Terminate Handler" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 6. Termination</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="dynamic_memory.html">Prev</a> </td><th width="60%" align="center">Part II. 
- Support
-
-</th><td width="20%" align="right"> <a accesskey="n" href="verbose_termination.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.support.termination"></a>Chapter 6. Termination</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="termination.html#support.termination.handlers">Termination Handlers</a></span></dt><dt><span class="sect1"><a href="verbose_termination.html">Verbose Terminate Handler</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="support.termination.handlers"></a>Termination Handlers</h2></div></div></div><p>
- Not many changes here to <code class="filename">cstdlib</code>. You should note that the
- <code class="function">abort()</code> function does not call the
- destructors of automatic nor static objects, so if you're
- depending on those to do cleanup, it isn't going to happen.
- (The functions registered with <code class="function">atexit()</code>
- don't get called either, so you can forget about that
- possibility, too.)
- </p><p>
- The good old <code class="function">exit()</code> function can be a bit
- funky, too, until you look closer. Basically, three points to
- remember are:
- </p><div class="orderedlist"><ol type="1"><li><p>
- Static objects are destroyed in reverse order of their creation.
- </p></li><li><p>
- Functions registered with <code class="function">atexit()</code> are called in
- reverse order of registration, once per registration call.
- (This isn't actually new.)
- </p></li><li><p>
- The previous two actions are “<span class="quote">interleaved,</span>” that is,
- given this pseudocode:
- </p><pre class="programlisting">
- extern "C or C++" void f1 (void);
- extern "C or C++" void f2 (void);
-
- static Thing obj1;
- atexit(f1);
- static Thing obj2;
- atexit(f2);
-</pre><p>
- then at a call of <code class="function">exit()</code>,
- <code class="varname">f2</code> will be called, then
- <code class="varname">obj2</code> will be destroyed, then
- <code class="varname">f1</code> will be called, and finally
- <code class="varname">obj1</code> will be destroyed. If
- <code class="varname">f1</code> or <code class="varname">f2</code> allow an
- exception to propagate out of them, Bad Things happen.
- </p></li></ol></div><p>
- Note also that <code class="function">atexit()</code> is only required to store 32
- functions, and the compiler/library might already be using some of
- those slots. If you think you may run out, we recommend using
- the <code class="function">xatexit</code>/<code class="function">xexit</code> combination from <code class="literal">libiberty</code>, which has no such limit.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="dynamic_memory.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="support.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="verbose_termination.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 5. Dynamic Memory </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Verbose Terminate Handler</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/test.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/test.html
deleted file mode 100644
index aa5e0e3b1..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/test.html
+++ /dev/null
@@ -1,489 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Test</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; test&#10; , &#10; testsuite&#10; , &#10; performance&#10; , &#10; conformance&#10; , &#10; ABI&#10; , &#10; exception safety&#10; " /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="setup.html" title="Chapter 2. Setup" /><link rel="prev" href="make.html" title="Make" /><link rel="next" href="using.html" title="Chapter 3. Using" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Test</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="make.html">Prev</a> </td><th width="60%" align="center">Chapter 2. Setup</th><td width="20%" align="right"> <a accesskey="n" href="using.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.setup.test"></a>Test</h2></div></div></div><p>
-The libstdc++ testsuite includes testing for standard conformance,
-regressions, ABI, and performance.
-</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="test.organization"></a>Organization</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="test.organization.layout"></a>Directory Layout</h4></div></div></div><p>
- The directory <span class="emphasis"><em>libsrcdir/testsuite</em></span> contains the
- individual test cases organized in sub-directories corresponding to
- chapters of the C++ standard (detailed below), the dejagnu test
- harness support files, and sources to various testsuite utilities
- that are packaged in a separate testing library.
-</p><p>
- All test cases for functionality required by the runtime components
- of the C++ standard (ISO 14882) are files within the following
- directories.
-</p><pre class="programlisting">
-17_intro
-18_support
-19_diagnostics
-20_util
-21_strings
-22_locale
-23_containers
-25_algorithms
-26_numerics
-27_io
- </pre><p>
- In addition, the following directories include test files:
- </p><pre class="programlisting">
-tr1 Tests for components as described by the Technical Report on Standard Library Extensions (TR1).
-backward Tests for backwards compatibility and deprecated features.
-demangle Tests for __cxa_demangle, the IA 64 C++ ABI demangler
-ext Tests for extensions.
-performance Tests for performance analysis, and performance regressions.
-thread Tests for threads.
- </pre><p>
- Some directories don't have test files, but instead contain
- auxiliary information (<a class="ulink" href="#internals" target="_top">more information</a>):
- </p><pre class="programlisting">
-config Files for the dejagnu test harness.
-lib Files for the dejagnu test harness.
-libstdc++* Files for the dejagnu test harness.
-data Sample text files for testing input and output.
-util Files for libtestc++, utilities and testing routines.
- </pre><p>
- Within a directory that includes test files, there may be
- additional subdirectories, or files. Originally, test cases
- were appended to one file that represented a particular section
- of the chapter under test, and was named accordingly. For
- instance, to test items related to <code class="code"> 21.3.6.1 -
- basic_string::find [lib.string::find]</code> in the standard,
- the following was used:
- </p><pre class="programlisting">
-21_strings/find.cc
- </pre><p>
- However, that practice soon became a liability as the test cases
- became huge and unwieldy, and testing new or extended
- functionality (like wide characters or named locales) became
- frustrating, leading to aggressive pruning of test cases on some
- platforms that covered up implementation errors. Now, the test
- suite has a policy of one file, one test case, which solves the
- above issues and gives finer grained results and more manageable
- error debugging. As an example, the test case quoted above
- becomes:
- </p><pre class="programlisting">
-21_strings/basic_string/find/char/1.cc
-21_strings/basic_string/find/char/2.cc
-21_strings/basic_string/find/char/3.cc
-21_strings/basic_string/find/wchar_t/1.cc
-21_strings/basic_string/find/wchar_t/2.cc
-21_strings/basic_string/find/wchar_t/3.cc
- </pre><p>
- All new tests should be written with the policy of one test
- case, one file in mind.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="test.organization.naming"></a>Naming Conventions</h4></div></div></div><p>
- In addition, there are some special names and suffixes that are
- used within the testsuite to designate particular kinds of
- tests.
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- <span class="emphasis"><em>_xin.cc</em></span>
- </p><p>
- This test case expects some kind of interactive input in order
- to finish or pass. At the moment, the interactive tests are not
- run by default. Instead, they are run by hand, like:
- </p><pre class="programlisting">
-g++ 27_io/objects/char/3_xin.cc
-cat 27_io/objects/char/3_xin.in | a.out
- </pre></li><li><p>
- <span class="emphasis"><em>.in</em></span>
- </p><p>
- This file contains the expected input for the corresponding <span class="emphasis"><em>
- _xin.cc</em></span> test case.
- </p></li><li><p>
- <span class="emphasis"><em>_neg.cc</em></span>
- </p><p>
- This test case is expected to fail: it's a negative test. At the
- moment, these are almost always compile time errors.
- </p></li><li><p>
- <span class="emphasis"><em>char</em></span>
- </p><p>
- This can either be a directory name or part of a longer file
- name, and indicates that this file, or the files within this
- directory are testing the <code class="code">char</code> instantiation of a
- template.
- </p></li><li><p>
- <span class="emphasis"><em>wchar_t</em></span>
- </p><p>
- This can either be a directory name or part of a longer file
- name, and indicates that this file, or the files within this
- directory are testing the <code class="code">wchar_t</code> instantiation of
- a template. Some hosts do not support <code class="code">wchar_t</code>
- functionality, so for these targets, all of these tests will not
- be run.
- </p></li><li><p>
- <span class="emphasis"><em>thread</em></span>
- </p><p>
- This can either be a directory name or part of a longer file
- name, and indicates that this file, or the files within this
- directory are testing situations where multiple threads are
- being used.
- </p></li><li><p>
- <span class="emphasis"><em>performance</em></span>
- </p><p>
- This can either be an enclosing directory name or part of a
- specific file name. This indicates a test that is used to
- analyze runtime performance, for performance regression testing,
- or for other optimization related analysis. At the moment, these
- test cases are not run by default.
- </p></li></ul></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="test.run"></a>Running the Testsuite</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="test.run.basic"></a>Basic</h4></div></div></div><p>
- You can check the status of the build without installing it
- using the dejagnu harness, much like the rest of the gcc
- tools.</p><pre class="programlisting"> make check</pre><p>in the <span class="emphasis"><em>libbuilddir</em></span> directory.</p><p>or</p><pre class="programlisting"> make check-target-libstdc++-v3</pre><p>in the <span class="emphasis"><em>gccbuilddir</em></span> directory.
- </p><p>
- These commands are functionally equivalent and will create a
- 'testsuite' directory underneath
- <span class="emphasis"><em>libbuilddir</em></span> containing the results of the
- tests. Two results files will be generated: <span class="emphasis"><em>
- libstdc++.sum</em></span>, which is a PASS/FAIL summary for each
- test, and <span class="emphasis"><em>libstdc++.log</em></span> which is a log of
- the exact command line passed to the compiler, the compiler
- output, and the executable output (if any).
- </p><p>
- Archives of test results for various versions and platforms are
- available on the GCC website in the <a class="ulink" href="http://gcc.gnu.org/gcc-4.3/buildstat.html" target="_top">build
- status</a> section of each individual release, and are also
- archived on a daily basis on the <a class="ulink" href="http://gcc.gnu.org/ml/gcc-testresults/current" target="_top">gcc-testresults</a>
- mailing list. Please check either of these places for a similar
- combination of source version, operating system, and host CPU.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="test.run.variations"></a>Variations</h4></div></div></div><p>
- There are several options for running tests, including testing
- the regression tests, testing a subset of the regression tests,
- testing the performance tests, testing just compilation, testing
- installed tools, etc. In addition, there is a special rule for
- checking the exported symbols of the shared library.
- </p><p>
- To debug the dejagnu test harness during runs, try invoking with a
- specific argument to the variable RUNTESTFLAGS, as below.
- </p><pre class="programlisting">
-make check-target-libstdc++-v3 RUNTESTFLAGS="-v"
-</pre><p>
- or
- </p><pre class="programlisting">
-make check-target-libstdc++-v3 RUNTESTFLAGS="-v -v"
-</pre><p>
- To run a subset of the library tests, you will need to generate
- the <span class="emphasis"><em>testsuite_files</em></span> file by running
- <span class="command"><strong>make testsuite_files</strong></span> in the
- <span class="emphasis"><em>libbuilddir/testsuite</em></span> directory, described
- below. Edit the file to remove the tests you don't want and
- then run the testsuite as normal.
- </p><p>
- There are two ways to run on a simulator: set up DEJAGNU to point to a
- specially crafted site.exp, or pass down --target_board flags.
- </p><p>
- Example flags to pass down for various embedded builds are as follows:
- </p><pre class="programlisting">
- --target=powerpc-eabism (libgloss/sim)
-make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=powerpc-sim"
-
---target=calmrisc32 (libgloss/sid)
-make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=calmrisc32-sid"
-
---target=xscale-elf (newlib/sim)
-make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=arm-sim"
-</pre><p>
- Also, here is an example of how to run the libstdc++ testsuite
- for a multilibed build directory with different ABI settings:
- </p><pre class="programlisting">
-make check-target-libstdc++-v3 RUNTESTFLAGS='--target_board \"unix{-mabi=32,,-mabi=64}\"'
-</pre><p>
- You can run the tests with a compiler and library that have
- already been installed. Make sure that the compiler (e.g.,
- <code class="code">g++</code>) is in your <code class="code">PATH</code>. If you are
- using shared libraries, then you must also ensure that the
- directory containing the shared version of libstdc++ is in your
- <code class="code">LD_LIBRARY_PATH</code>, or equivalent. If your GCC source
- tree is at <code class="code">/path/to/gcc</code>, then you can run the tests
- as follows:
- </p><pre class="programlisting">
-runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite
-</pre><p>
- The testsuite will create a number of files in the directory in
- which you run this command,. Some of those files might use the
- same name as files created by other testsuites (like the ones
- for GCC and G++), so you should not try to run all the
- testsuites in parallel from the same directory.
- </p><p>
- In addition, there are some testing options that are mostly of
- interest to library maintainers and system integrators. As such,
- these tests may not work on all cpu and host combinations, and
- may need to be executed in the
- <span class="emphasis"><em>libbuilddir/testsuite</em></span> directory. These
- options include, but are not necessarily limited to, the
- following:
- </p><pre class="programlisting">
- make testsuite_files
- </pre><p>
- Five files are generated that determine what test files
- are run. These files are:
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- <span class="emphasis"><em>testsuite_files</em></span>
- </p><p>
- This is a list of all the test cases that will be run. Each
- test case is on a separate line, given with an absolute path
- from the <span class="emphasis"><em>libsrcdir/testsuite</em></span> directory.
- </p></li><li><p>
- <span class="emphasis"><em>testsuite_files_interactive</em></span>
- </p><p>
- This is a list of all the interactive test cases, using the
- same format as the file list above. These tests are not run
- by default.
- </p></li><li><p>
- <span class="emphasis"><em>testsuite_files_performance</em></span>
- </p><p>
- This is a list of all the performance test cases, using the
- same format as the file list above. These tests are not run
- by default.
- </p></li><li><p>
- <span class="emphasis"><em>testsuite_thread</em></span>
- </p><p>
- This file indicates that the host system can run tests which
- involved multiple threads.
- </p></li><li><p>
- <span class="emphasis"><em>testsuite_wchar_t</em></span>
- </p><p>
- This file indicates that the host system can run the wchar_t
- tests, and corresponds to the macro definition <code class="code">
- _GLIBCXX_USE_WCHAR_T</code> in the file c++config.h.
- </p></li></ul></div><pre class="programlisting">
- make check-abi
- </pre><p>
- The library ABI can be tested. This involves testing the shared
- library against an ABI-defining previous version of symbol
- exports.
- </p><pre class="programlisting">
- make check-compile
- </pre><p>
- This rule compiles, but does not link or execute, the
- <span class="emphasis"><em>testsuite_files</em></span> test cases and displays the
- output on stdout.
- </p><pre class="programlisting">
- make check-performance
- </pre><p>
- This rule runs through the
- <span class="emphasis"><em>testsuite_files_performance</em></span> test cases and
- collects information for performance analysis and can be used to
- spot performance regressions. Various timing information is
- collected, as well as number of hard page faults, and memory
- used. This is not run by default, and the implementation is in
- flux.
- </p><p>
- We are interested in any strange failures of the testsuite;
- please email the main libstdc++ mailing list if you see
- something odd or have questions.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="test.run.permutations"></a>Permutations</h4></div></div></div><p>
- To run the libstdc++ test suite under the <a class="link" href="debug_mode.html" title="Chapter 30. Debug Mode">debug mode</a>, edit
- <code class="filename">libstdc++-v3/scripts/testsuite_flags</code> to add the
- compile-time flag <code class="constant">-D_GLIBCXX_DEBUG</code> to the
- result printed by the <code class="literal">--build-cxx</code>
- option. Additionally, add the
- <code class="constant">-D_GLIBCXX_DEBUG_PEDANTIC</code> flag to turn on
- pedantic checking. The libstdc++ test suite should produce
- precisely the same results under debug mode that it does under
- release mode: any deviation indicates an error in either the
- library or the test suite.
- </p><p>
- The <a class="link" href="parallel_mode.html" title="Chapter 31. Parallel Mode">parallel
- mode</a> can be tested in much the same manner, substituting
- <code class="constant">-D_GLIBCXX_PARALLEL</code> for
- <code class="constant">-D_GLIBCXX_DEBUG</code> in the previous paragraph.
- </p><p>
- Or, just run the testsuites with <code class="constant">CXXFLAGS</code>
- set to <code class="constant">-D_GLIBCXX_DEBUG</code> or
- <code class="constant">-D_GLIBCXX_PARALLEL</code>.
- </p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="test.new_tests"></a>Writing a new test case</h3></div></div></div><p>
- The first step in making a new test case is to choose the correct
- directory and file name, given the organization as previously
- described.
- </p><p>
- All files are copyright the FSF, and GPL'd: this is very
- important. The first copyright year should correspond to the date
- the file was checked in to SVN.
- </p><p>
- As per the dejagnu instructions, always return 0 from main to
- indicate success.
- </p><p>
- A bunch of utility functions and classes have already been
- abstracted out into the testsuite utility library, <code class="code">
- libtestc++</code>. To use this functionality, just include the
- appropriate header file: the library or specific object files will
- automatically be linked in as part of the testsuite run.
- </p><p>
- For a test that needs to take advantage of the dejagnu test
- harness, what follows below is a list of special keyword that
- harness uses. Basically, a test case contains dg-keywords (see
- dg.exp) indicating what to do and what kinds of behavior are to be
- expected. New test cases should be written with the new style
- DejaGnu framework in mind.
- </p><p>
- To ease transition, here is the list of dg-keyword documentation
- lifted from dg.exp.
- </p><pre class="programlisting">
-# The currently supported options are:
-#
-# dg-prms-id N
-# set prms_id to N
-#
-# dg-options "options ..." [{ target selector }]
-# specify special options to pass to the tool (eg: compiler)
-#
-# dg-do do-what-keyword [{ target/xfail selector }]
-# `do-what-keyword' is tool specific and is passed unchanged to
-# ${tool}-dg-test. An example is gcc where `keyword' can be any of:
-# preprocess|compile|assemble|link|run
-# and will do one of: produce a .i, produce a .s, produce a .o,
-# produce an a.out, or produce an a.out and run it (the default is
-# compile).
-#
-# dg-error regexp comment [{ target/xfail selector } [{.|0|linenum}]]
-# indicate an error message &lt;regexp&gt; is expected on this line
-# (the test fails if it doesn't occur)
-# Linenum=0 for general tool messages (eg: -V arg missing).
-# "." means the current line.
-#
-# dg-warning regexp comment [{ target/xfail selector } [{.|0|linenum}]]
-# indicate a warning message &lt;regexp&gt; is expected on this line
-# (the test fails if it doesn't occur)
-#
-# dg-bogus regexp comment [{ target/xfail selector } [{.|0|linenum}]]
-# indicate a bogus error message &lt;regexp&gt; use to occur here
-# (the test fails if it does occur)
-#
-# dg-build regexp comment [{ target/xfail selector }]
-# indicate the build use to fail for some reason
-# (errors covered here include bad assembler generated, tool crashes,
-# and link failures)
-# (the test fails if it does occur)
-#
-# dg-excess-errors comment [{ target/xfail selector }]
-# indicate excess errors are expected (any line)
-# (this should only be used sparingly and temporarily)
-#
-# dg-output regexp [{ target selector }]
-# indicate the expected output of the program is &lt;regexp&gt;
-# (there may be multiple occurrences of this, they are concatenated)
-#
-# dg-final { tcl code }
-# add some tcl code to be run at the end
-# (there may be multiple occurrences of this, they are concatenated)
-# (unbalanced braces must be \-escaped)
-#
-# "{ target selector }" is a list of expressions that determine whether the
-# test succeeds or fails for a particular target, or in some cases whether the
-# option applies for a particular target. If the case of `dg-do' it specifies
-# whether the test case is even attempted on the specified target.
-#
-# The target selector is always optional. The format is one of:
-#
-# { xfail *-*-* ... } - the test is expected to fail for the given targets
-# { target *-*-* ... } - the option only applies to the given targets
-#
-# At least one target must be specified, use *-*-* for "all targets".
-# At present it is not possible to specify both `xfail' and `target'.
-# "native" may be used in place of "*-*-*".
-
-Example 1: Testing compilation only
-// { dg-do compile }
-
-Example 2: Testing for expected warnings on line 36, which all targets fail
-// { dg-warning "string literals" "" { xfail *-*-* } 36
-
-Example 3: Testing for expected warnings on line 36
-// { dg-warning "string literals" "" { target *-*-* } 36
-
-Example 4: Testing for compilation errors on line 41
-// { dg-do compile }
-// { dg-error "no match for" "" { target *-*-* } 41 }
-
-Example 5: Testing with special command line settings, or without the
-use of pre-compiled headers, in particular the stdc++.h.gch file. Any
-options here will override the DEFAULT_CXXFLAGS and PCH_CXXFLAGS set
-up in the normal.exp file.
-// { dg-options "-O0" { target *-*-* } }
-</pre><p>
- More examples can be found in the libstdc++-v3/testsuite/*/*.cc files.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="test.harness"></a>Test Harness and Utilities</h3></div></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="test.harness.dejagnu"></a>Dejagnu Harness Details</h4></div></div></div><p>
- Underlying details of testing for conformance and regressions are
- abstracted via the GNU Dejagnu package. This is similar to the
- rest of GCC.
- </p><p>This is information for those looking at making changes to the testsuite
-structure, and/or needing to trace dejagnu's actions with --verbose. This
-will not be useful to people who are "merely" adding new tests to the existing
-structure.
-</p><p>The first key point when working with dejagnu is the idea of a "tool".
-Files, directories, and functions are all implicitly used when they are
-named after the tool in use. Here, the tool will always be "libstdc++".
-</p><p>The <code class="code">lib</code> subdir contains support routines. The
-<code class="code">lib/libstdc++.exp</code> file ("support library") is loaded
-automagically, and must explicitly load the others. For example, files can
-be copied from the core compiler's support directory into <code class="code">lib</code>.
-</p><p>Some routines in <code class="code">lib/libstdc++.exp</code> are callbacks, some are
-our own. Callbacks must be prefixed with the name of the tool. To easily
-distinguish the others, by convention our own routines are named "v3-*".
-</p><p>The next key point when working with dejagnu is "test files". Any
-directory whose name starts with the tool name will be searched for test files.
-(We have only one.) In those directories, any <code class="code">.exp</code> file is
-considered a test file, and will be run in turn. Our main test file is called
-<code class="code">normal.exp</code>; it runs all the tests in testsuite_files using the
-callbacks loaded from the support library.
-</p><p>The <code class="code">config</code> directory is searched for any particular "target
-board" information unique to this library. This is currently unused and sets
-only default variables.
-</p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="test.harness.utils"></a>Utilities</h4></div></div></div><p>
- </p><p>
- The testsuite directory also contains some files that implement
- functionality that is intended to make writing test cases easier,
- or to avoid duplication, or to provide error checking in a way that
- is consistent across platforms and test harnesses. A stand-alone
- executable, called <span class="emphasis"><em>abi_check</em></span>, and a static
- library called <span class="emphasis"><em>libtestc++</em></span> are
- constructed. Both of these items are not installed, and only used
- during testing.
- </p><p>
- These files include the following functionality:
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- <span class="emphasis"><em>testsuite_abi.h</em></span>,
- <span class="emphasis"><em>testsuite_abi.cc</em></span>,
- <span class="emphasis"><em>testsuite_abi_check.cc</em></span>
- </p><p>
- Creates the executable <span class="emphasis"><em>abi_check</em></span>.
- Used to check correctness of symbol versioning, visibility of
- exported symbols, and compatibility on symbols in the shared
- library, for hosts that support this feature. More information
- can be found in the ABI documentation <a class="ulink" href="abi.html" target="_top">here</a>
- </p></li><li><p>
- <span class="emphasis"><em>testsuite_allocator.h</em></span>,
- <span class="emphasis"><em>testsuite_allocator.cc</em></span>
- </p><p>
- Contains specialized allocators that keep track of construction
- and destruction. Also, support for overriding global new and
- delete operators, including verification that new and delete
- are called during execution, and that allocation over max_size
- fails.
- </p></li><li><p>
- <span class="emphasis"><em>testsuite_character.h</em></span>
- </p><p>
- Contains <code class="code">std::char_traits</code> and
- <code class="code">std::codecvt</code> specializations for a user-defined
- POD.
- </p></li><li><p>
- <span class="emphasis"><em>testsuite_hooks.h</em></span>,
- <span class="emphasis"><em>testsuite_hooks.cc</em></span>
- </p><p>
- A large number of utilities, including:
- </p><div class="itemizedlist"><ul type="circle"><li><p>VERIFY</p></li><li><p>set_memory_limits</p></li><li><p>verify_demangle</p></li><li><p>run_tests_wrapped_locale</p></li><li><p>run_tests_wrapped_env</p></li><li><p>try_named_locale</p></li><li><p>try_mkfifo</p></li><li><p>func_callback</p></li><li><p>counter</p></li><li><p>copy_tracker</p></li><li><p>copy_constructor</p></li><li><p>assignment_operator</p></li><li><p>destructor</p></li><li><p>pod_char, pod_int and associated char_traits specializations</p></li></ul></div></li><li><p>
- <span class="emphasis"><em>testsuite_io.h</em></span>
- </p><p>
- Error, exception, and constraint checking for
- <code class="code">std::streambuf, std::basic_stringbuf, std::basic_filebuf</code>.
- </p></li><li><p>
- <span class="emphasis"><em>testsuite_iterators.h</em></span>
- </p><p>
- Wrappers for various iterators.
- </p></li><li><p>
- <span class="emphasis"><em>testsuite_performance.h</em></span>
- </p><p>
- A number of class abstractions for performance counters, and
- reporting functions including:
- </p><div class="itemizedlist"><ul type="circle"><li><p>time_counter</p></li><li><p>resource_counter</p></li><li><p>report_performance</p></li></ul></div></li></ul></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="make.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="setup.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="using.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Make </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 3. Using</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/traits.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/traits.html
deleted file mode 100644
index 708370044..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/traits.html
+++ /dev/null
@@ -1,10 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 12. Traits</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="utilities.html" title="Part IV.  Utilities" /><link rel="prev" href="shared_ptr.html" title="shared_ptr" /><link rel="next" href="strings.html" title="Part V.  Strings" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 12. Traits</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="shared_ptr.html">Prev</a> </td><th width="60%" align="center">Part IV. 
- Utilities
-
-</th><td width="20%" align="right"> <a accesskey="n" href="strings.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.util.traits"></a>Chapter 12. Traits</h2></div></div></div><p>
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="shared_ptr.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="utilities.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="strings.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">shared_ptr </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part V. 
- Strings
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/using.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/using.html
deleted file mode 100644
index 0bf3c7b5c..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/using.html
+++ /dev/null
@@ -1,44 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 3. Using</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="intro.html" title="Part I.  Introduction" /><link rel="prev" href="test.html" title="Test" /><link rel="next" href="using_headers.html" title="Headers" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 3. Using</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="test.html">Prev</a> </td><th width="60%" align="center">Part I. 
- Introduction
-
-</th><td width="20%" align="right"> <a accesskey="n" href="using_headers.html">Next</a></td></tr></table><hr /></div><div class="chapter" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="manual.intro.using"></a>Chapter 3. Using</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="using.html#manual.intro.using.lib">Linking Library Binary Files</a></span></dt><dt><span class="sect1"><a href="using_headers.html">Headers</a></span></dt><dd><dl><dt><span class="sect2"><a href="using_headers.html#manual.intro.using.headers.all">Header Files</a></span></dt><dt><span class="sect2"><a href="using_headers.html#manual.intro.using.headers.mixing">Mixing Headers</a></span></dt><dt><span class="sect2"><a href="using_headers.html#manual.intro.using.headers.cheaders">The C Headers and namespace std</a></span></dt><dt><span class="sect2"><a href="using_headers.html#manual.intro.using.headers.pre">Precompiled Headers</a></span></dt></dl></dd><dt><span class="sect1"><a href="using_namespaces.html">Namespaces</a></span></dt><dd><dl><dt><span class="sect2"><a href="using_namespaces.html#manual.intro.using.namespaces.all">Available Namespaces</a></span></dt><dt><span class="sect2"><a href="using_namespaces.html#manual.intro.using.namespaces.std">namespace std</a></span></dt><dt><span class="sect2"><a href="using_namespaces.html#manual.intro.using.namespaces.comp">Using Namespace Composition</a></span></dt></dl></dd><dt><span class="sect1"><a href="using_macros.html">Macros</a></span></dt><dt><span class="sect1"><a href="using_concurrency.html">Concurrency</a></span></dt><dd><dl><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.prereq">Prerequisites</a></span></dt><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.thread_safety">Thread Safety</a></span></dt><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.atomics">Atomics</a></span></dt><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.io">IO</a></span></dt><dt><span class="sect2"><a href="using_concurrency.html#manual.intro.using.concurrency.containers">Containers</a></span></dt></dl></dd><dt><span class="sect1"><a href="using_exceptions.html">Exceptions</a></span></dt><dd><dl><dt><span class="sect2"><a href="using_exceptions.html#intro.using.exception.propagating">Propagating Exceptions aka Exception Neutrality</a></span></dt><dt><span class="sect2"><a href="using_exceptions.html#intro.using.exception.safety">Exception Safety</a></span></dt><dt><span class="sect2"><a href="using_exceptions.html#intro.using.exception.no">Support for -fno-exceptions</a></span></dt></dl></dd><dt><span class="sect1"><a href="debug.html">Debugging Support</a></span></dt><dd><dl><dt><span class="sect2"><a href="debug.html#debug.compiler">Using g++</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.req">Debug Versions of Library Binary Files</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.memory">Memory Leak Hunting</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.gdb">Using gdb</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.exceptions">Tracking uncaught exceptions</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.debug_mode">Debug Mode</a></span></dt><dt><span class="sect2"><a href="debug.html#debug.compile_time_checks">Compile Time Checking</a></span></dt></dl></dd></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.lib"></a>Linking Library Binary Files</h2></div></div></div><p>
- If you only built a static library (libstdc++.a), or if you
- specified static linking, you don't have to worry about this.
- But if you built a shared library (libstdc++.so) and linked
- against it, then you will need to find that library when you run
- the executable.
- </p><p>
- Methods vary for different platforms and different styles, but
- the usual ones are printed to the screen during installation.
- They include:
- </p><div class="itemizedlist"><ul type="disc"><li><p>
- At runtime set LD_LIBRARY_PATH in your environment
- correctly, so that the shared library for libstdc++ can be
- found and loaded. Be certain that you understand all of the
- other implications and behavior of LD_LIBRARY_PATH first
- (few people do, and they get into trouble).
- </p></li><li><p>
- Compile the path to find the library at runtime into the
- program. This can be done by passing certain options to
- g++, which will in turn pass them on to the linker. The
- exact format of the options is dependent on which linker you
- use:
- </p><div class="itemizedlist"><ul type="circle"><li><p>
- GNU ld (default on Linux):<code class="literal">-Wl,--rpath,<code class="filename">destdir</code>/lib</code>
- </p></li><li><p>
- IRIX ld:<code class="literal">
- -Wl,-rpath,<code class="filename">destdir</code>/lib</code>
- </p></li><li><p>
- Solaris ld:<code class="literal">-Wl,-R<code class="filename">destdir</code>/lib</code>
- </p></li><li><p>
- More...? Let us know!
- </p></li></ul></div></li></ul></div><p>
- Use the <span class="command"><strong>ldd</strong></span> utility to show which library the
- system thinks it will get at runtime.
- </p><p>
- A libstdc++.la file is also installed, for use with Libtool. If
- you use Libtool to create your executables, these details are
- taken care of for you.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="test.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="intro.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="using_headers.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Test </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Headers</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_concurrency.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_concurrency.html
deleted file mode 100644
index 2ddde83a1..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_concurrency.html
+++ /dev/null
@@ -1,219 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Concurrency</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="using_macros.html" title="Macros" /><link rel="next" href="using_exceptions.html" title="Exceptions" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Concurrency</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="using_macros.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="using_exceptions.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.concurrency"></a>Concurrency</h2></div></div></div><p>This section discusses issues surrounding the proper compilation
- of multithreaded applications which use the Standard C++
- library. This information is GCC-specific since the C++
- standard does not address matters of multithreaded applications.
- </p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.concurrency.prereq"></a>Prerequisites</h3></div></div></div><p>All normal disclaimers aside, multithreaded C++ application are
- only supported when libstdc++ and all user code was built with
- compilers which report (via <code class="code"> gcc/g++ -v </code>) the same thread
- model and that model is not <span class="emphasis"><em>single</em></span>. As long as your
- final application is actually single-threaded, then it should be
- safe to mix user code built with a thread model of
- <span class="emphasis"><em>single</em></span> with a libstdc++ and other C++ libraries built
- with another thread model useful on the platform. Other mixes
- may or may not work but are not considered supported. (Thus, if
- you distribute a shared C++ library in binary form only, it may
- be best to compile it with a GCC configured with
- --enable-threads for maximal interchangeability and usefulness
- with a user population that may have built GCC with either
- --enable-threads or --disable-threads.)
- </p><p>When you link a multithreaded application, you will probably
- need to add a library or flag to g++. This is a very
- non-standardized area of GCC across ports. Some ports support a
- special flag (the spelling isn't even standardized yet) to add
- all required macros to a compilation (if any such flags are
- required then you must provide the flag for all compilations not
- just linking) and link-library additions and/or replacements at
- link time. The documentation is weak. Here is a quick summary
- to display how ad hoc this is: On Solaris, both -pthreads and
- -threads (with subtly different meanings) are honored. On OSF,
- -pthread and -threads (with subtly different meanings) are
- honored. On Linux/i386, -pthread is honored. On FreeBSD,
- -pthread is honored. Some other ports use other switches.
- AFAIK, none of this is properly documented anywhere other than
- in ``gcc -dumpspecs'' (look at lib and cpp entries).
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.concurrency.thread_safety"></a>Thread Safety</h3></div></div></div><p>
-We currently use the <a class="ulink" href="http://www.sgi.com/tech/stl/thread_safety.html" target="_top">SGI STL</a> definition of thread safety.
-</p><p>The library strives to be thread-safe when all of the following
- conditions are met:
- </p><div class="itemizedlist"><ul type="disc"><li><p>The system's libc is itself thread-safe,
- </p></li><li><p>
- The compiler in use reports a thread model other than
- 'single'. This can be tested via output from <code class="code">gcc
- -v</code>. Multi-thread capable versions of gcc output
- something like this:
- </p><pre class="programlisting">
-%gcc -v
-Using built-in specs.
-...
-Thread model: posix
-gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
-</pre><p>Look for "Thread model" lines that aren't equal to "single."</p></li><li><p>
- Requisite command-line flags are used for atomic operations
- and threading. Examples of this include <code class="code">-pthread</code>
- and <code class="code">-march=native</code>, although specifics vary
- depending on the host environment. See <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html" target="_top">Machine
- Dependent Options</a>.
- </p></li><li><p>
- An implementation of atomicity.h functions
- exists for the architecture in question. See the internals documentation for more <a class="ulink" href="../ext/concurrence.html" target="_top">details</a>.
- </p></li></ul></div><p>The user-code must guard against concurrent method calls which may
- access any particular library object's state. Typically, the
- application programmer may infer what object locks must be held
- based on the objects referenced in a method call. Without getting
- into great detail, here is an example which requires user-level
- locks:
- </p><pre class="programlisting">
- library_class_a shared_object_a;
-
- thread_main () {
- library_class_b *object_b = new library_class_b;
- shared_object_a.add_b (object_b); // must hold lock for shared_object_a
- shared_object_a.mutate (); // must hold lock for shared_object_a
- }
-
- // Multiple copies of thread_main() are started in independent threads.</pre><p>Under the assumption that object_a and object_b are never exposed to
- another thread, here is an example that should not require any
- user-level locks:
- </p><pre class="programlisting">
- thread_main () {
- library_class_a object_a;
- library_class_b *object_b = new library_class_b;
- object_a.add_b (object_b);
- object_a.mutate ();
- } </pre><p>All library objects are safe to use in a multithreaded program as
- long as each thread carefully locks out access by any other
- thread while it uses any object visible to another thread, i.e.,
- treat library objects like any other shared resource. In general,
- this requirement includes both read and write access to objects;
- unless otherwise documented as safe, do not assume that two threads
- may access a shared standard library object at the same time.
- </p><p>See chapters <a class="ulink" href="../17_intro/howto.html#3" target="_top">17</a> (library
- introduction), <a class="ulink" href="../23_containers/howto.html#3" target="_top">23</a>
- (containers), and <a class="ulink" href="../27_io/howto.html#9" target="_top">27</a> (I/O) for
- more information.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.concurrency.atomics"></a>Atomics</h3></div></div></div><p>
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.concurrency.io"></a>IO</h3></div></div></div><p>I'll assume that you have already read the
- <a class="ulink" href="../17_intro/howto.html#3" target="_top">general notes on library threads</a>,
- and the
- <a class="ulink" href="../23_containers/howto.html#3" target="_top">notes on threaded container
- access</a> (you might not think of an I/O stream as a container, but
- the points made there also hold here). If you have not read them,
- please do so first.
- </p><p>This gets a bit tricky. Please read carefully, and bear with me.
- </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="concurrency.io.structure"></a>Structure</h4></div></div></div><p>A wrapper
- type called <code class="code">__basic_file</code> provides our abstraction layer
- for the <code class="code">std::filebuf</code> classes. Nearly all decisions dealing
- with actual input and output must be made in <code class="code">__basic_file</code>.
- </p><p>A generic locking mechanism is somewhat in place at the filebuf layer,
- but is not used in the current code. Providing locking at any higher
- level is akin to providing locking within containers, and is not done
- for the same reasons (see the links above).
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="concurrency.io.defaults"></a>Defaults</h4></div></div></div><p>The __basic_file type is simply a collection of small wrappers around
- the C stdio layer (again, see the link under Structure). We do no
- locking ourselves, but simply pass through to calls to <code class="code">fopen</code>,
- <code class="code">fwrite</code>, and so forth.
- </p><p>So, for 3.0, the question of "is multithreading safe for I/O"
- must be answered with, "is your platform's C library threadsafe
- for I/O?" Some are by default, some are not; many offer multiple
- implementations of the C library with varying tradeoffs of threadsafety
- and efficiency. You, the programmer, are always required to take care
- with multiple threads.
- </p><p>(As an example, the POSIX standard requires that C stdio FILE*
- operations are atomic. POSIX-conforming C libraries (e.g, on Solaris
- and GNU/Linux) have an internal mutex to serialize operations on
- FILE*s. However, you still need to not do stupid things like calling
- <code class="code">fclose(fs)</code> in one thread followed by an access of
- <code class="code">fs</code> in another.)
- </p><p>So, if your platform's C library is threadsafe, then your
- <code class="code">fstream</code> I/O operations will be threadsafe at the lowest
- level. For higher-level operations, such as manipulating the data
- contained in the stream formatting classes (e.g., setting up callbacks
- inside an <code class="code">std::ofstream</code>), you need to guard such accesses
- like any other critical shared resource.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="concurrency.io.future"></a>Future</h4></div></div></div><p> A
- second choice may be available for I/O implementations: libio. This is
- disabled by default, and in fact will not currently work due to other
- issues. It will be revisited, however.
- </p><p>The libio code is a subset of the guts of the GNU libc (glibc) I/O
- implementation. When libio is in use, the <code class="code">__basic_file</code>
- type is basically derived from FILE. (The real situation is more
- complex than that... it's derived from an internal type used to
- implement FILE. See libio/libioP.h to see scary things done with
- vtbls.) The result is that there is no "layer" of C stdio
- to go through; the filebuf makes calls directly into the same
- functions used to implement <code class="code">fread</code>, <code class="code">fwrite</code>,
- and so forth, using internal data structures. (And when I say
- "makes calls directly," I mean the function is literally
- replaced by a jump into an internal function. Fast but frightening.
- *grin*)
- </p><p>Also, the libio internal locks are used. This requires pulling in
- large chunks of glibc, such as a pthreads implementation, and is one
- of the issues preventing widespread use of libio as the libstdc++
- cstdio implementation.
- </p><p>But we plan to make this work, at least as an option if not a future
- default. Platforms running a copy of glibc with a recent-enough
- version will see calls from libstdc++ directly into the glibc already
- installed. For other platforms, a copy of the libio subsection will
- be built and included in libstdc++.
- </p></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="concurrency.io.alt"></a>Alternatives</h4></div></div></div><p>Don't forget that other cstdio implementations are possible. You could
- easily write one to perform your own forms of locking, to solve your
- "interesting" problems.
- </p></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.concurrency.containers"></a>Containers</h3></div></div></div><p>This section discusses issues surrounding the design of
- multithreaded applications which use Standard C++ containers.
- All information in this section is current as of the gcc 3.0
- release and all later point releases. Although earlier gcc
- releases had a different approach to threading configuration and
- proper compilation, the basic code design rules presented here
- were similar. For information on all other aspects of
- multithreading as it relates to libstdc++, including details on
- the proper compilation of threaded code (and compatibility between
- threaded and non-threaded code), see Chapter 17.
- </p><p>Two excellent pages to read when working with the Standard C++
- containers and threads are
- <a class="ulink" href="http://www.sgi.com/tech/stl/thread_safety.html" target="_top">SGI's
- http://www.sgi.com/tech/stl/thread_safety.html</a> and
- <a class="ulink" href="http://www.sgi.com/tech/stl/Allocators.html" target="_top">SGI's
- http://www.sgi.com/tech/stl/Allocators.html</a>.
- </p><p><span class="emphasis"><em>However, please ignore all discussions about the user-level
- configuration of the lock implementation inside the STL
- container-memory allocator on those pages. For the sake of this
- discussion, libstdc++ configures the SGI STL implementation,
- not you. This is quite different from how gcc pre-3.0 worked.
- In particular, past advice was for people using g++ to
- explicitly define _PTHREADS or other macros or port-specific
- compilation options on the command line to get a thread-safe
- STL. This is no longer required for any port and should no
- longer be done unless you really know what you are doing and
- assume all responsibility.</em></span>
- </p><p>Since the container implementation of libstdc++ uses the SGI
- code, we use the same definition of thread safety as SGI when
- discussing design. A key point that beginners may miss is the
- fourth major paragraph of the first page mentioned above
- ("For most clients,"...), which points out that
- locking must nearly always be done outside the container, by
- client code (that'd be you, not us). There is a notable
- exceptions to this rule. Allocators called while a container or
- element is constructed uses an internal lock obtained and
- released solely within libstdc++ code (in fact, this is the
- reason STL requires any knowledge of the thread configuration).
- </p><p>For implementing a container which does its own locking, it is
- trivial to provide a wrapper class which obtains the lock (as
- SGI suggests), performs the container operation, and then
- releases the lock. This could be templatized <span class="emphasis"><em>to a certain
- extent</em></span>, on the underlying container and/or a locking
- mechanism. Trying to provide a catch-all general template
- solution would probably be more trouble than it's worth.
- </p><p>The STL implementation is currently configured to use the
- high-speed caching memory allocator. Some people like to
- test and/or normally run threaded programs with a different
- default. For all details about how to globally override this
- at application run-time see <a class="ulink" href="../ext/howto.html#3" target="_top">here</a>.
- </p><p>There is a better way (not standardized yet): It is possible to
- force the malloc-based allocator on a per-case-basis for some
- application code. The library team generally believes that this
- is a better way to tune an application for high-speed using this
- implementation of the STL. There is
- <a class="ulink" href="../ext/howto.html#3" target="_top">more information on allocators here</a>.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="using_macros.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="using_exceptions.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Macros </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Exceptions</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_exceptions.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_exceptions.html
deleted file mode 100644
index 123c459be..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_exceptions.html
+++ /dev/null
@@ -1,6 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Exceptions</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="using_concurrency.html" title="Concurrency" /><link rel="next" href="debug.html" title="Debugging Support" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Exceptions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="using_concurrency.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="debug.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.exception"></a>Exceptions</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="intro.using.exception.propagating"></a>Propagating Exceptions aka Exception Neutrality</h3></div></div></div><p>
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="intro.using.exception.safety"></a>Exception Safety</h3></div></div></div><p>
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="intro.using.exception.no"></a>Support for <code class="literal">-fno-exceptions</code></h3></div></div></div><p>
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="using_concurrency.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="debug.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Concurrency </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Debugging Support</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_headers.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_headers.html
deleted file mode 100644
index be531fb4b..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_headers.html
+++ /dev/null
@@ -1,101 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Headers</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="using.html" title="Chapter 3. Using" /><link rel="next" href="using_namespaces.html" title="Namespaces" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Headers</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="using.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="using_namespaces.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.headers"></a>Headers</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.headers.all"></a>Header Files</h3></div></div></div><p>
- The C++ standard specifies the entire set of header files that
- must be available to all hosted implementations. Actually, the
- word "files" is a misnomer, since the contents of the
- headers don't necessarily have to be in any kind of external
- file. The only rule is that when one <code class="code">#include</code>'s a
- header, the contents of that header become available, no matter
- how.
- </p><p>
- That said, in practice files are used.
- </p><p>
- There are two main types of include files: header files related
- to a specific version of the ISO C++ standard (called Standard
- Headers), and all others (TR1, C++ ABI, and Extensions).
- </p><p>
- Two dialects of standard headers are supported, corresponding to
- the 1998 standard as updated for 2003, and the draft of the
- upcoming 200x standard.
- </p><p>
- C++98/03 include files. These are available in the default compilation mode, i.e. <code class="code">-std=c++98</code> or <code class="code">-std=gnu++98</code>.
- </p><div class="table"><a id="id425445"></a><p class="title"><b>Table 3.1. C++ 1998 Library Headers</b></p><div class="table-contents"><table summary="C++ 1998 Library Headers" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col /></colgroup><tbody><tr><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="filename">bitset</code></td><td align="left"><code class="filename">complex</code></td><td align="left"><code class="filename">deque</code></td><td align="left"><code class="filename">exception</code></td></tr><tr><td align="left"><code class="filename">fstream</code></td><td align="left"><code class="filename">functional</code></td><td align="left"><code class="filename">iomanip</code></td><td align="left"><code class="filename">ios</code></td><td align="left"><code class="filename">iosfwd</code></td></tr><tr><td align="left"><code class="filename">iostream</code></td><td align="left"><code class="filename">istream</code></td><td align="left"><code class="filename">iterator</code></td><td align="left"><code class="filename">limits</code></td><td align="left"><code class="filename">list</code></td></tr><tr><td align="left"><code class="filename">locale</code></td><td align="left"><code class="filename">map</code></td><td align="left"><code class="filename">memory</code></td><td align="left"><code class="filename">new</code></td><td align="left"><code class="filename">numeric</code></td></tr><tr><td align="left"><code class="filename">ostream</code></td><td align="left"><code class="filename">queue</code></td><td align="left"><code class="filename">set</code></td><td align="left"><code class="filename">sstream</code></td><td align="left"><code class="filename">stack</code></td></tr><tr><td align="left"><code class="filename">stdexcept</code></td><td align="left"><code class="filename">streambuf</code></td><td align="left"><code class="filename">string</code></td><td align="left"><code class="filename">utility</code></td><td align="left"><code class="filename">typeinfo</code></td></tr><tr><td align="left"><code class="filename">valarray</code></td><td align="left"><code class="filename">vector</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p></p><div class="table"><a id="id401915"></a><p class="title"><b>Table 3.2. C++ 1998 Library Headers for C Library Facilities</b></p><div class="table-contents"><table summary="C++ 1998 Library Headers for C Library Facilities" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col /></colgroup><tbody><tr><td align="left"><code class="filename">cassert</code></td><td align="left"><code class="filename">cerrno</code></td><td align="left"><code class="filename">cctype</code></td><td align="left"><code class="filename">cfloat</code></td><td align="left"><code class="filename">ciso646</code></td></tr><tr><td align="left"><code class="filename">climits</code></td><td align="left"><code class="filename">clocale</code></td><td align="left"><code class="filename">cmath</code></td><td align="left"><code class="filename">csetjmp</code></td><td align="left"><code class="filename">csignal</code></td></tr><tr><td align="left"><code class="filename">cstdarg</code></td><td align="left"><code class="filename">cstddef</code></td><td align="left"><code class="filename">cstdio</code></td><td align="left"><code class="filename">cstdlib</code></td><td align="left"><code class="filename">cstring</code></td></tr><tr><td align="left"><code class="filename">ctime</code></td><td align="left"><code class="filename">cwchar</code></td><td align="left"><code class="filename">cwctype</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p>
-C++0x include files. These are only available in C++0x compilation
-mode, i.e. <code class="literal">-std=c++0x</code> or <code class="literal">-std=gnu++0x</code>.
-</p><p></p><div class="table"><a id="id400861"></a><p class="title"><b>Table 3.3. C++ 200x Library Headers</b></p><div class="table-contents"><table summary="C++ 200x Library Headers" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col /></colgroup><tbody><tr><td align="left"><code class="filename">algorithm</code></td><td align="left"><code class="filename">array</code></td><td align="left"><code class="filename">bitset</code></td><td align="left"><code class="filename">chrono</code></td><td align="left"><code class="filename">complex</code></td></tr><tr><td align="left"><code class="filename">condition_variable</code></td><td align="left"><code class="filename">deque</code></td><td align="left"><code class="filename">exception</code></td><td align="left"><code class="filename">forward_list</code></td><td align="left"><code class="filename">fstream</code></td></tr><tr><td align="left"><code class="filename">functional</code></td><td align="left"><code class="filename">initalizer_list</code></td><td align="left"><code class="filename">iomanip</code></td><td align="left"><code class="filename">ios</code></td><td align="left"><code class="filename">iosfwd</code></td></tr><tr><td align="left"><code class="filename">iostream</code></td><td align="left"><code class="filename">istream</code></td><td align="left"><code class="filename">iterator</code></td><td align="left"><code class="filename">limits</code></td><td align="left"><code class="filename">list</code></td></tr><tr><td align="left"><code class="filename">locale</code></td><td align="left"><code class="filename">map</code></td><td align="left"><code class="filename">memory</code></td><td align="left"><code class="filename">mutex</code></td><td align="left"><code class="filename">new</code></td></tr><tr><td align="left"><code class="filename">numeric</code></td><td align="left"><code class="filename">ostream</code></td><td align="left"><code class="filename">queue</code></td><td align="left"><code class="filename">random</code></td><td align="left"><code class="filename">ratio</code></td></tr><tr><td align="left"><code class="filename">regex</code></td><td align="left"><code class="filename">set</code></td><td align="left"><code class="filename">sstream</code></td><td align="left"><code class="filename">stack</code></td><td align="left"><code class="filename">stdexcept</code></td></tr><tr><td align="left"><code class="filename">streambuf</code></td><td align="left"><code class="filename">string</code></td><td align="left"><code class="filename">system_error</code></td><td align="left"><code class="filename">thread</code></td><td align="left"><code class="filename">tuple</code></td></tr><tr><td align="left"><code class="filename">type_traits</code></td><td align="left"><code class="filename">typeinfo</code></td><td align="left"><code class="filename">unordered_map</code></td><td align="left"><code class="filename">unordered_set</code></td><td align="left"><code class="filename">utility</code></td></tr><tr><td align="left"><code class="filename">valarray</code></td><td align="left"><code class="filename">vector</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p></p><div class="table"><a id="id419917"></a><p class="title"><b>Table 3.4. C++ 200x Library Headers for C Library Facilities</b></p><div class="table-contents"><table summary="C++ 200x Library Headers for C Library Facilities" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">cassert</code></td><td align="left"><code class="filename">ccomplex</code></td><td align="left"><code class="filename">cctype</code></td><td align="left"><code class="filename">cerrno</code></td><td align="left"><code class="filename">cfenv</code></td></tr><tr><td align="left"><code class="filename">cfloat</code></td><td align="left"><code class="filename">cinttypes</code></td><td align="left"><code class="filename">ciso646</code></td><td align="left"><code class="filename">climits</code></td><td align="left"><code class="filename">clocale</code></td></tr><tr><td align="left"><code class="filename">cmath</code></td><td align="left"><code class="filename">csetjmp</code></td><td align="left"><code class="filename">csignal</code></td><td align="left"><code class="filename">cstdarg</code></td><td align="left"><code class="filename">cstdatomic</code></td></tr><tr><td align="left"><code class="filename">cstdbool</code></td><td align="left"><code class="filename">cstddef</code></td><td align="left"><code class="filename">cstdint</code></td><td align="left"><code class="filename">cstdlib</code></td><td align="left"><code class="filename">cstdio</code></td></tr><tr><td align="left"><code class="filename">cstring</code></td><td align="left"><code class="filename">ctgmath</code></td><td align="left"><code class="filename">ctime</code></td><td align="left"><code class="filename">cuchar</code></td><td align="left"><code class="filename">cwchar</code></td></tr><tr><td align="left"><code class="filename">cwctype</code></td><td align="left"><code class="filename">stdatomic.h</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p>
- In addition, TR1 includes as:
-</p><div class="table"><a id="id409697"></a><p class="title"><b>Table 3.5. C++ TR1 Library Headers</b></p><div class="table-contents"><table summary="C++ TR1 Library Headers" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">tr1/array</code></td><td align="left"><code class="filename">tr1/complex</code></td><td align="left"><code class="filename">tr1/memory</code></td><td align="left"><code class="filename">tr1/functional</code></td><td align="left"><code class="filename">tr1/random</code></td></tr><tr><td align="left"><code class="filename">tr1/regex</code></td><td align="left"><code class="filename">tr1/tuple</code></td><td align="left"><code class="filename">tr1/type_traits</code></td><td align="left"><code class="filename">tr1/unordered_map</code></td><td align="left"><code class="filename">tr1/unordered_set</code></td></tr><tr><td align="left"><code class="filename">tr1/utility</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p></p><div class="table"><a id="id458482"></a><p class="title"><b>Table 3.6. C++ TR1 Library Headers for C Library Facilities</b></p><div class="table-contents"><table summary="C++ TR1 Library Headers for C Library Facilities" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">tr1/ccomplex</code></td><td align="left"><code class="filename">tr1/cfenv</code></td><td align="left"><code class="filename">tr1/cfloat</code></td><td align="left"><code class="filename">tr1/cmath</code></td><td align="left"><code class="filename">tr1/cinttypes</code></td></tr><tr><td align="left"><code class="filename">tr1/climits</code></td><td align="left"><code class="filename">tr1/cstdarg</code></td><td align="left"><code class="filename">tr1/cstdbool</code></td><td align="left"><code class="filename">tr1/cstdint</code></td><td align="left"><code class="filename">tr1/cstdio</code></td></tr><tr><td align="left"><code class="filename">tr1/cstdlib</code></td><td align="left"><code class="filename">tr1/ctgmath</code></td><td align="left"><code class="filename">tr1/ctime</code></td><td align="left"><code class="filename">tr1/cwchar</code></td><td align="left"><code class="filename">tr1/cwctype</code></td></tr></tbody></table></div></div><br class="table-break" /><p>
- Also included are files for the C++ ABI interface:
-</p><div class="table"><a id="id406531"></a><p class="title"><b>Table 3.7. C++ ABI Headers</b></p><div class="table-contents"><table summary="C++ ABI Headers" border="1"><colgroup><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">cxxabi.h</code></td><td align="left"><code class="filename">cxxabi_forced.h</code></td></tr></tbody></table></div></div><br class="table-break" /><p>
- And a large variety of extensions.
-</p><div class="table"><a id="id519638"></a><p class="title"><b>Table 3.8. Extension Headers</b></p><div class="table-contents"><table summary="Extension Headers" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">ext/algorithm</code></td><td align="left"><code class="filename">ext/atomicity.h</code></td><td align="left"><code class="filename">ext/array_allocator.h</code></td><td align="left"><code class="filename">ext/bitmap_allocator.h</code></td><td align="left"><code class="filename">ext/cast.h</code></td></tr><tr><td align="left"><code class="filename">ext/codecvt_specializations.h</code></td><td align="left"><code class="filename">ext/concurrence.h</code></td><td align="left"><code class="filename">ext/debug_allocator.h</code></td><td align="left"><code class="filename">ext/enc_filebuf.h</code></td><td align="left"><code class="filename">ext/extptr_allocator.h</code></td></tr><tr><td align="left"><code class="filename">ext/functional</code></td><td align="left"><code class="filename">ext/iterator</code></td><td align="left"><code class="filename">ext/malloc_allocator.h</code></td><td align="left"><code class="filename">ext/memory</code></td><td align="left"><code class="filename">ext/mt_allocator.h</code></td></tr><tr><td align="left"><code class="filename">ext/new_allocator.h</code></td><td align="left"><code class="filename">ext/numeric</code></td><td align="left"><code class="filename">ext/numeric_traits.h</code></td><td align="left"><code class="filename">ext/pb_ds/assoc_container.h</code></td><td align="left"><code class="filename">ext/pb_ds/priority_queue.h</code></td></tr><tr><td align="left"><code class="filename">ext/pod_char_traits.h</code></td><td align="left"><code class="filename">ext/pool_allocator.h</code></td><td align="left"><code class="filename">ext/rb_tree</code></td><td align="left"><code class="filename">ext/rope</code></td><td align="left"><code class="filename">ext/slist</code></td></tr><tr><td align="left"><code class="filename">ext/stdio_filebuf.h</code></td><td align="left"><code class="filename">ext/stdio_sync_filebuf.h</code></td><td align="left"><code class="filename">ext/throw_allocator.h</code></td><td align="left"><code class="filename">ext/typelist.h</code></td><td align="left"><code class="filename">ext/type_traits.h</code></td></tr><tr><td align="left"><code class="filename">ext/vstring.h</code></td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p></p><div class="table"><a id="id423635"></a><p class="title"><b>Table 3.9. Extension Debug Headers</b></p><div class="table-contents"><table summary="Extension Debug Headers" border="1"><colgroup><col align="left" /><col align="left" /><col align="left" /><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">debug/bitset</code></td><td align="left"><code class="filename">debug/deque</code></td><td align="left"><code class="filename">debug/list</code></td><td align="left"><code class="filename">debug/map</code></td><td align="left"><code class="filename">debug/set</code></td></tr><tr><td align="left"><code class="filename">debug/string</code></td><td align="left"><code class="filename">debug/unordered_map</code></td><td align="left"><code class="filename">debug/unordered_set</code></td><td align="left"><code class="filename">debug/vector</code></td><td class="auto-generated"> </td></tr></tbody></table></div></div><br class="table-break" /><p></p><div class="table"><a id="id410706"></a><p class="title"><b>Table 3.10. Extension Parallel Headers</b></p><div class="table-contents"><table summary="Extension Parallel Headers" border="1"><colgroup><col align="left" /><col align="left" /></colgroup><tbody><tr><td align="left"><code class="filename">parallel/algorithm</code></td><td align="left"><code class="filename">parallel/numeric</code></td></tr></tbody></table></div></div><br class="table-break" /></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.headers.mixing"></a>Mixing Headers</h3></div></div></div><p> A few simple rules.
-</p><p>First, mixing different dialects of the standard headers is not
-possible. It's an all-or-nothing affair. Thus, code like
-</p><pre class="programlisting">
-#include &lt;array&gt;
-#include &lt;functional&gt;
-</pre><p>Implies C++0x mode. To use the entities in &lt;array&gt;, the C++0x
-compilation mode must be used, which implies the C++0x functionality
-(and deprecations) in &lt;functional&gt; will be present.
-</p><p>Second, the other headers can be included with either dialect of
-the standard headers, although features and types specific to C++0x
-are still only enabled when in C++0x compilation mode. So, to use
-rvalue references with <code class="code">__gnu_cxx::vstring</code>, or to use the
-debug-mode versions of <code class="code">std::unordered_map</code>, one must use
-the <code class="code">std=gnu++0x</code> compiler flag. (Or <code class="code">std=c++0x</code>, of course.)
-</p><p>A special case of the second rule is the mixing of TR1 and C++0x
-facilities. It is possible (although not especially prudent) to
-include both the TR1 version and the C++0x version of header in the
-same translation unit:
-</p><pre class="programlisting">
-#include &lt;tr1/type_traits&gt;
-#include &lt;type_traits&gt;
-</pre><p> Several parts of C++0x diverge quite substantially from TR1 predecessors.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.headers.cheaders"></a>The C Headers and <code class="code">namespace std</code></h3></div></div></div><p>
- The standard specifies that if one includes the C-style header
- (&lt;math.h&gt; in this case), the symbols will be available
- in the global namespace and perhaps in
- namespace <code class="code">std::</code> (but this is no longer a firm
- requirement.) One the other hand, including the C++-style
- header (&lt;cmath&gt;) guarantees that the entities will be
- found in namespace std and perhaps in the global namespace.
- </p><p>
-Usage of C++-style headers is recommended, as then
-C-linkage names can be disambiguated by explicit qualification, such
-as by <code class="code">std::abort</code>. In addition, the C++-style headers can
-use function overloading to provide a simpler interface to certain
-families of C-functions. For instance in &lt;cmath&gt;, the
-function <code class="code">std::sin</code> has overloads for all the builtin
-floating-point types. This means that <code class="code">std::sin</code> can be
-used uniformly, instead of a combination
-of <code class="code">std::sinf</code>, <code class="code">std::sin</code>,
-and <code class="code">std::sinl</code>.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.headers.pre"></a>Precompiled Headers</h3></div></div></div><p>There are three base header files that are provided. They can be
-used to precompile the standard headers and extensions into binary
-files that may the be used to speed compiles that use these headers.
-</p><div class="itemizedlist"><ul type="disc"><li><p>stdc++.h</p><p>Includes all standard headers. Actual content varies depending on
-language dialect.
-</p></li><li><p>stdtr1c++.h</p><p>Includes all of &lt;stdc++.h&gt;, and adds all the TR1 headers.
-</p></li><li><p>extc++.h</p><p>Includes all of &lt;stdtr1c++.h&gt;, and adds all the Extension headers.
-</p></li></ul></div><p>How to construct a .gch file from one of these base header files.</p><p>First, find the include directory for the compiler. One way to do
-this is:</p><pre class="programlisting">
-g++ -v hello.cc
-
-#include &lt;...&gt; search starts here:
- /mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0
-...
-End of search list.
-</pre><p>Then, create a precompiled header file with the same flags that
-will be used to compile other projects.</p><pre class="programlisting">
-g++ -Winvalid-pch -x c++-header -g -O2 -o ./stdc++.h.gch /mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0/x86_64-unknown-linux-gnu/bits/stdc++.h
-</pre><p>The resulting file will be quite large: the current size is around
-thirty megabytes. </p><p>How to use the resulting file.</p><pre class="programlisting">
-g++ -I. -include stdc++.h -H -g -O2 hello.cc
-</pre><p>Verification that the PCH file is being used is easy:</p><pre class="programlisting">
-g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 hello.cc -o test.exe
-! ./stdc++.h.gch
-. /mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0/iostream
-. /mnt/share/bld/H-x86-gcc.20071201include/c++/4.3.0/string
-</pre><p>The exclamation point to the left of the <code class="code">stdc++.h.gch</code> listing means that the generated PCH file was used, and thus the </p><p></p><p> Detailed information about creating precompiled header files can be found in the GCC <a class="ulink" href="http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html" target="_top">documentation</a>.
-</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="using.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="using_namespaces.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 3. Using </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Namespaces</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_macros.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_macros.html
deleted file mode 100644
index 1ff70f494..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_macros.html
+++ /dev/null
@@ -1,70 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Macros</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="using_namespaces.html" title="Namespaces" /><link rel="next" href="using_concurrency.html" title="Concurrency" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Macros</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="using_namespaces.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="using_concurrency.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.macros"></a>Macros</h2></div></div></div><p>All pre-processor switches and configurations are all gathered
- in the file <code class="code">c++config.h</code>, which is generated during
- the libstdc++ configuration and build process, and included by
- files part of the public libstdc++ API. Most of these macros
- should not be used by consumers of libstdc++, and are reserved
- for internal implementation use. <span class="emphasis"><em>These macros cannot be
- redefined</em></span>. However, a select handful of these macro
- control libstdc++ extensions and extra features, or provide
- versioning information for the API, and are able to be used.
- </p><p>All library macros begin with <code class="code">_GLIBCXX_</code> (except for
- versions 3.1.x to 3.3.x, which use <code class="code">_GLIBCPP_</code>).
- </p><p>Below is the macro which users may check for library version
- information. </p><div class="variablelist"><dl><dt><span class="term"><code class="code">__GLIBCXX__</code></span></dt><dd><p>The current version of
- libstdc++ in compressed ISO date format, form of an unsigned
- long. For details on the value of this particular macro for a
- particular release, please consult this <a class="ulink" href="abi.html" target="_top">
- document</a>.
- </p></dd></dl></div><p>Below are the macros which users may change with #define/#undef or
- with -D/-U compiler flags. The default state of the symbol is
- listed.</p><p>“<span class="quote">Configurable</span>” (or “<span class="quote">Not configurable</span>”) means
- that the symbol is initially chosen (or not) based on
- --enable/--disable options at library build and configure time
- (documented <a class="link" href="configure.html" title="Configure">here</a>), with the
- various --enable/--disable choices being translated to
- #define/#undef).
- </p><p> <acronym class="acronym">ABI</acronym> means that changing from the default value may
- mean changing the <acronym class="acronym">ABI</acronym> of compiled code. In other words, these
- choices control code which has already been compiled (i.e., in a
- binary such as libstdc++.a/.so). If you explicitly #define or
- #undef these macros, the <span class="emphasis"><em>headers</em></span> may see different code
- paths, but the <span class="emphasis"><em>libraries</em></span> which you link against will not.
- Experimenting with different values with the expectation of
- consistent linkage requires changing the config headers before
- building/installing the library.
- </p><div class="variablelist"><dl><dt><span class="term"><code class="code">_GLIBCXX_DEPRECATED</code></span></dt><dd><p>
- Defined by default. Not configurable. ABI-changing. Turning this off
- removes older ARM-style iostreams code, and other anachronisms
- from the API. This macro is dependent on the version of the
- standard being tracked, and as a result may give different results for
- <code class="code">-std=c++98</code> and <code class="code">-std=c++0x</code>. This may
- be useful in updating old C++ code which no longer meet the
- requirements of the language, or for checking current code
- against new language standards.
- </p></dd><dt><span class="term"><code class="code">_GLIBCXX_FORCE_NEW</code></span></dt><dd><p>
- Undefined by default. When defined, memory allocation and
- allocators controlled by libstdc++ call operator new/delete
- without caching and pooling. Configurable via
- <code class="code">--enable-libstdcxx-allocator</code>. ABI-changing.
- </p></dd><dt><span class="term"><code class="code">_GLIBCXX_CONCEPT_CHECKS</code></span></dt><dd><p>
- Undefined by default. Configurable via
- <code class="code">--enable-concept-checks</code>. When defined, performs
- compile-time checking on certain template instantiations to
- detect violations of the requirements of the standard. This
- is described in more detail <a class="ulink" href="../19_diagnostics/howto.html#3" target="_top">here</a>.
- </p></dd><dt><span class="term"><code class="code">_GLIBCXX_DEBUG</code></span></dt><dd><p>
- Undefined by default. When defined, compiles
- user code using the <a class="ulink" href="../ext/debug.html#safe" target="_top">libstdc++ debug
- mode</a>.
- </p></dd><dt><span class="term"><code class="code">_GLIBCXX_DEBUG_PEDANTIC</code></span></dt><dd><p>
- Undefined by default. When defined while
- compiling with the <a class="ulink" href="../ext/debug.html#safe" target="_top">libstdc++ debug
- mode</a>, makes the debug mode extremely picky by making the use
- of libstdc++ extensions and libstdc++-specific behavior into
- errors.
- </p></dd><dt><span class="term"><code class="code">_GLIBCXX_PARALLEL</code></span></dt><dd><p>Undefined by default. When defined, compiles
- user code using the <a class="ulink" href="../ext/parallel_mode.html" target="_top">libstdc++ parallel
- mode</a>.
- </p></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="using_namespaces.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="using_concurrency.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Namespaces </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Concurrency</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_namespaces.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_namespaces.html
deleted file mode 100644
index f39feac52..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/using_namespaces.html
+++ /dev/null
@@ -1,61 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Namespaces</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="using.html" title="Chapter 3. Using" /><link rel="prev" href="using_headers.html" title="Headers" /><link rel="next" href="using_macros.html" title="Macros" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Namespaces</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="using_headers.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Using</th><td width="20%" align="right"> <a accesskey="n" href="using_macros.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.using.namespaces"></a>Namespaces</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.namespaces.all"></a>Available Namespaces</h3></div></div></div><p> There are three main namespaces.
-</p><div class="itemizedlist"><ul type="disc"><li><p>std</p><p>The ISO C++ standards specify that "all library entities are defined
-within namespace std." This includes namespaces nested
-within <code class="code">namespace std</code>, such as <code class="code">namespace
-std::tr1</code>.
-</p></li><li><p>abi</p><p>Specified by the C++ ABI. This ABI specifies a number of type and
-function APIs supplemental to those required by the ISO C++ Standard,
-but necessary for interoperability.
-</p></li><li><p>__gnu_</p><p>Indicating one of several GNU extensions. Choices
-include <code class="code">__gnu_cxx</code>, <code class="code">__gnu_debug</code>, <code class="code">__gnu_parallel</code>,
-and <code class="code">__gnu_pbds</code>.
-</p></li></ul></div><p> A complete list of implementation namespaces (including namespace contents) is available in the generated source <a class="ulink" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/namespaces.html" target="_top">documentation</a>.
-</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.namespaces.std"></a>namespace std</h3></div></div></div><p>
- One standard requirement is that the library components are defined
- in <code class="code">namespace std::</code>. Thus, in order to use these types or
- functions, one must do one of two things:
-</p><div class="itemizedlist"><ul type="disc"><li><p>put a kind of <span class="emphasis"><em>using-declaration</em></span> in your source
-(either <code class="code">using namespace std;</code> or i.e. <code class="code">using
-std::string;</code>) This approach works well for individual source files, but
-should not be used in a global context, like header files.
- </p></li><li><p>use a <span class="emphasis"><em>fully
-qualified name</em></span>for each library symbol
-(i.e. <code class="code">std::string</code>, <code class="code">std::cout</code>) Always can be
-used, and usually enhanced, by strategic use of typedefs. (In the
-cases where the qualified verbiage becomes unwieldy.)
- </p></li></ul></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.using.namespaces.comp"></a>Using Namespace Composition</h3></div></div></div><p>
-Best practice in programming suggests sequestering new data or
-functionality in a sanely-named, unique namespace whenever
-possible. This is considered an advantage over dumping everything in
-the global namespace, as then name look-up can be explicitly enabled or
-disabled as above, symbols are consistently mangled without repetitive
-naming prefixes or macros, etc.
-</p><p>For instance, consider a project that defines most of its classes in <code class="code">namespace gtk</code>. It is possible to
- adapt <code class="code">namespace gtk</code> to <code class="code">namespace std</code> by using a C++-feature called
- <span class="emphasis"><em>namespace composition</em></span>. This is what happens if
- a <span class="emphasis"><em>using</em></span>-declaration is put into a
- namespace-definition: the imported symbol(s) gets imported into the
- currently active namespace(s). For example:
-</p><pre class="programlisting">
-namespace gtk
-{
- using std::string;
- using std::tr1::array;
-
- class Window { ... };
-}
-</pre><p>
- In this example, <code class="code">std::string</code> gets imported into
- <code class="code">namespace gtk</code>. The result is that use of
- <code class="code">std::string</code> inside namespace gtk can just use <code class="code">string</code>, without the explicit qualification.
- As an added bonus,
- <code class="code">std::string</code> does not get imported into
- the global namespace. Additionally, a more elaborate arrangement can be made for backwards compatibility and portability, whereby the
- <code class="code">using</code>-declarations can wrapped in macros that
- are set based on autoconf-tests to either "" or i.e. <code class="code">using
- std::string;</code> (depending on whether the system has
- libstdc++ in <code class="code">std::</code> or not). (ideas from
- <code class="email">&lt;<a class="email" href="mailto:llewelly@dbritsch.dsl.xmission.com">llewelly@dbritsch.dsl.xmission.com</a>&gt;</code>, Karl Nelson <code class="email">&lt;<a class="email" href="mailto:kenelson@ece.ucdavis.edu">kenelson@ece.ucdavis.edu</a>&gt;</code>)
-</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="using_headers.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="using.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="using_macros.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Headers </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Macros</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/utilities.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/utilities.html
deleted file mode 100644
index cbf7d51d8..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/utilities.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Part IV.  Utilities</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="spine.html" title="The GNU C++ Library" /><link rel="prev" href="bk01pt03ch07s03.html" title="Cancellation" /><link rel="next" href="functors.html" title="Chapter 9. Functors" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Part IV. 
- Utilities
-
-</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk01pt03ch07s03.html">Prev</a> </td><th width="60%" align="center">The GNU C++ Library</th><td width="20%" align="right"> <a accesskey="n" href="functors.html">Next</a></td></tr></table><hr /></div><div class="part" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="manual.util"></a>Part IV. 
- Utilities
- <a id="id416762" class="indexterm"></a>
-</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="functors.html">9. Functors</a></span></dt><dt><span class="chapter"><a href="pairs.html">10. Pairs</a></span></dt><dt><span class="chapter"><a href="memory.html">11. Memory</a></span></dt><dd><dl><dt><span class="sect1"><a href="memory.html#manual.util.memory.allocator">Allocators</a></span></dt><dd><dl><dt><span class="sect2"><a href="memory.html#allocator.req">Requirements</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.using">Using a Specific Allocator</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.custom">Custom Allocators</a></span></dt><dt><span class="sect2"><a href="memory.html#allocator.ext">Extension Allocators</a></span></dt></dl></dd><dt><span class="sect1"><a href="auto_ptr.html">auto_ptr</a></span></dt><dd><dl><dt><span class="sect2"><a href="auto_ptr.html#auto_ptr.limitations">Limitations</a></span></dt><dt><span class="sect2"><a href="auto_ptr.html#auto_ptr.using">Use in Containers</a></span></dt></dl></dd><dt><span class="sect1"><a href="shared_ptr.html">shared_ptr</a></span></dt><dd><dl><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.req">Requirements</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.using">Use</a></span></dt><dt><span class="sect2"><a href="shared_ptr.html#shared_ptr.ack">Acknowledgments</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="traits.html">12. Traits</a></span></dt></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk01pt03ch07s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="spine.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="functors.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Cancellation </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 9. Functors</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/vector.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/vector.html
deleted file mode 100644
index 2f80a7cda..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/vector.html
+++ /dev/null
@@ -1,16 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>vector</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="sequences.html" title="Chapter 16. Sequences" /><link rel="prev" href="sequences.html" title="Chapter 16. Sequences" /><link rel="next" href="associative.html" title="Chapter 17. Associative" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">vector</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="sequences.html">Prev</a> </td><th width="60%" align="center">Chapter 16. Sequences</th><td width="20%" align="right"> <a accesskey="n" href="associative.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="containers.sequences.vector"></a>vector</h2></div></div></div><p>
- </p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="sequences.vector.management"></a>Space Overhead Management</h3></div></div></div><p>
- In <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-04/msg00105.html" target="_top">this
- message to the list</a>, Daniel Kostecky announced work on an
- alternate form of <code class="code">std::vector</code> that would support
- hints on the number of elements to be over-allocated. The design
- was also described, along with possible implementation choices.
- </p><p>
- The first two alpha releases were announced <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-07/msg00048.html" target="_top">here</a>
- and <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2002-07/msg00111.html" target="_top">here</a>.
- The releases themselves are available at
- <a class="ulink" href="http://www.kotelna.sk/dk/sw/caphint/" target="_top">
- http://www.kotelna.sk/dk/sw/caphint/</a>.
- </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="sequences.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="sequences.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="associative.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 16. Sequences </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 17. Associative</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/manual/verbose_termination.html b/gcc-4.4.3/libstdc++-v3/doc/html/manual/verbose_termination.html
deleted file mode 100644
index a94172833..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/manual/verbose_termination.html
+++ /dev/null
@@ -1,79 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Verbose Terminate Handler</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content="&#10; ISO C++&#10; , &#10; library&#10; " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="termination.html" title="Chapter 6. Termination" /><link rel="prev" href="termination.html" title="Chapter 6. Termination" /><link rel="next" href="diagnostics.html" title="Part III.  Diagnostics" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Verbose Terminate Handler</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="termination.html">Prev</a> </td><th width="60%" align="center">Chapter 6. Termination</th><td width="20%" align="right"> <a accesskey="n" href="diagnostics.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="support.termination.verbose"></a>Verbose Terminate Handler</h2></div></div></div><p>
- If you are having difficulty with uncaught exceptions and want a
- little bit of help debugging the causes of the core dumps, you can
- make use of a GNU extension, the verbose terminate handler.
- </p><pre class="programlisting">
-#include &lt;exception&gt;
-
-int main()
-{
- std::set_terminate(__gnu_cxx::__verbose_terminate_handler);
- ...
-
- throw <em class="replaceable"><code>anything</code></em>;
-}
-</pre><p>
- The <code class="function">__verbose_terminate_handler</code> function
- obtains the name of the current exception, attempts to demangle
- it, and prints it to stderr. If the exception is derived from
- <code class="classname">exception</code> then the output from
- <code class="function">what()</code> will be included.
- </p><p>
- Any replacement termination function is required to kill the
- program without returning; this one calls abort.
- </p><p>
- For example:
- </p><pre class="programlisting">
-#include &lt;exception&gt;
-#include &lt;stdexcept&gt;
-
-struct argument_error : public std::runtime_error
-{
- argument_error(const std::string&amp; s): std::runtime_error(s) { }
-};
-
-int main(int argc)
-{
- std::set_terminate(__gnu_cxx::__verbose_terminate_handler);
- if (argc &gt; 5)
- throw argument_error(“<span class="quote">argc is greater than 5!</span>”);
- else
- throw argc;
-}
-</pre><p>
- With the verbose terminate handler active, this gives:
- </p><pre class="screen">
- <code class="computeroutput">
- % ./a.out
- terminate called after throwing a `int'
- Aborted
- % ./a.out f f f f f f f f f f f
- terminate called after throwing an instance of `argument_error'
- what(): argc is greater than 5!
- Aborted
- </code>
- </pre><p>
- The 'Aborted' line comes from the call to
- <code class="function">abort()</code>, of course.
- </p><p>
- This is the default termination handler; nothing need be done to
- use it. To go back to the previous “<span class="quote">silent death</span>”
- method, simply include <code class="filename">exception</code> and
- <code class="filename">cstdlib</code>, and call
- </p><pre class="programlisting">
- std::set_terminate(std::abort);
- </pre><p>
- After this, all calls to <code class="function">terminate</code> will use
- <code class="function">abort</code> as the terminate handler.
- </p><p>
- Note: the verbose terminate handler will attempt to write to
- stderr. If your application closes stderr or redirects it to an
- inappropriate location,
- <code class="function">__verbose_terminate_handler</code> will behave in
- an unspecified manner.
- </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="termination.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="termination.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="diagnostics.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 6. Termination </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Part III. 
- Diagnostics
-
-</td></tr></table></div></body></html>
diff --git a/gcc-4.4.3/libstdc++-v3/doc/html/spine.html b/gcc-4.4.3/libstdc++-v3/doc/html/spine.html
deleted file mode 100644
index 4758fde84..000000000
--- a/gcc-4.4.3/libstdc++-v3/doc/html/spine.html
+++ /dev/null
@@ -1,52 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The GNU C++ Library Documentation</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><link rel="home" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="next" href="manual/spine.html" title="The GNU C++ Library" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">The GNU C++ Library Documentation</th></tr><tr><td width="20%" align="left"> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="manual/spine.html">Next</a></td></tr></table><hr /></div><div class="set" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="set-index"></a>The GNU C++ Library Documentation</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Paolo</span> <span class="surname">Carlini</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Phil</span> <span class="surname">Edwards</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Doug</span> <span class="surname">Gregor</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Benjamin</span> <span class="surname">Kosnik</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Dhruv</span> <span class="surname">Matani</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Jason</span> <span class="surname">Merrill</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Mark</span> <span class="surname">Mitchell</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Nathan</span> <span class="surname">Myers</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Felix</span> <span class="surname">Natter</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Stefan</span> <span class="surname">Olsson</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Johannes</span> <span class="surname">Singler</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Ami</span> <span class="surname">Tavory</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Jonathan</span> <span class="surname">Wakely</span></h3></div></div></div><div><p class="copyright">Copyright © 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
- <a class="ulink" href="http://fsf.org" target="_top">FSF</a>
- </p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="book"><a href="manual/spine.html">The GNU C++ Library</a></span></dt><dd><dl><dt><span class="part"><a href="manual/intro.html">I.
- Introduction
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="manual/status.html">1. Status</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/status.html#manual.intro.status.standard">Implementation Status</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/status.html#manual.intro.status.standard.1998">C++ 1998/2003</a></span></dt><dt><span class="sect2"><a href="manual/status.html#manual.intro.status.standard.tr1">C++ TR1</a></span></dt><dt><span class="sect2"><a href="manual/status.html#manual.intro.status.standard.200x">C++ 200x</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/license.html">License</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/license.html#manual.intro.status.license.gpl">The Code: GPL</a></span></dt><dt><span class="sect2"><a href="manual/license.html#manual.intro.status.license.fdl">The Documentation: GPL, FDL</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/bugs.html">Bugs</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/bugs.html#manual.intro.status.bugs.impl">Implementation Bugs</a></span></dt><dt><span class="sect2"><a href="manual/bugs.html#manual.intro.status.bugs.iso">Standard Bugs</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="manual/setup.html">2. Setup</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/setup.html#manual.intro.setup.prereq">Prerequisites</a></span></dt><dt><span class="sect1"><a href="manual/configure.html">Configure</a></span></dt><dt><span class="sect1"><a href="manual/make.html">Make</a></span></dt><dt><span class="sect1"><a href="manual/test.html">Test</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/test.html#test.organization">Organization</a></span></dt><dt><span class="sect2"><a href="manual/test.html#test.run">Running the Testsuite</a></span></dt><dt><span class="sect2"><a href="manual/test.html#test.new_tests">Writing a new test case</a></span></dt><dt><span class="sect2"><a href="manual/test.html#test.harness">Test Harness and Utilities</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="manual/using.html">3. Using</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/using.html#manual.intro.using.lib">Linking Library Binary Files</a></span></dt><dt><span class="sect1"><a href="manual/using_headers.html">Headers</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/using_headers.html#manual.intro.using.headers.all">Header Files</a></span></dt><dt><span class="sect2"><a href="manual/using_headers.html#manual.intro.using.headers.mixing">Mixing Headers</a></span></dt><dt><span class="sect2"><a href="manual/using_headers.html#manual.intro.using.headers.cheaders">The C Headers and namespace std</a></span></dt><dt><span class="sect2"><a href="manual/using_headers.html#manual.intro.using.headers.pre">Precompiled Headers</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/using_namespaces.html">Namespaces</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/using_namespaces.html#manual.intro.using.namespaces.all">Available Namespaces</a></span></dt><dt><span class="sect2"><a href="manual/using_namespaces.html#manual.intro.using.namespaces.std">namespace std</a></span></dt><dt><span class="sect2"><a href="manual/using_namespaces.html#manual.intro.using.namespaces.comp">Using Namespace Composition</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/using_macros.html">Macros</a></span></dt><dt><span class="sect1"><a href="manual/using_concurrency.html">Concurrency</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/using_concurrency.html#manual.intro.using.concurrency.prereq">Prerequisites</a></span></dt><dt><span class="sect2"><a href="manual/using_concurrency.html#manual.intro.using.concurrency.thread_safety">Thread Safety</a></span></dt><dt><span class="sect2"><a href="manual/using_concurrency.html#manual.intro.using.concurrency.atomics">Atomics</a></span></dt><dt><span class="sect2"><a href="manual/using_concurrency.html#manual.intro.using.concurrency.io">IO</a></span></dt><dt><span class="sect2"><a href="manual/using_concurrency.html#manual.intro.using.concurrency.containers">Containers</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/using_exceptions.html">Exceptions</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/using_exceptions.html#intro.using.exception.propagating">Propagating Exceptions aka Exception Neutrality</a></span></dt><dt><span class="sect2"><a href="manual/using_exceptions.html#intro.using.exception.safety">Exception Safety</a></span></dt><dt><span class="sect2"><a href="manual/using_exceptions.html#intro.using.exception.no">Support for -fno-exceptions</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/debug.html">Debugging Support</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/debug.html#debug.compiler">Using g++</a></span></dt><dt><span class="sect2"><a href="manual/debug.html#debug.req">Debug Versions of Library Binary Files</a></span></dt><dt><span class="sect2"><a href="manual/debug.html#debug.memory">Memory Leak Hunting</a></span></dt><dt><span class="sect2"><a href="manual/debug.html#debug.gdb">Using gdb</a></span></dt><dt><span class="sect2"><a href="manual/debug.html#debug.exceptions">Tracking uncaught exceptions</a></span></dt><dt><span class="sect2"><a href="manual/debug.html#debug.debug_mode">Debug Mode</a></span></dt><dt><span class="sect2"><a href="manual/debug.html#debug.compile_time_checks">Compile Time Checking</a></span></dt></dl></dd></dl></dd></dl></dd><dt><span class="part"><a href="manual/support.html">II.
- Support
-
-</a></span></dt><dd><dl><dt><span class="preface"><a href="manual/bk01pt02pr01.html"></a></span></dt><dt><span class="chapter"><a href="manual/fundamental_types.html">4. Types</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/fundamental_types.html#manual.support.types.fundamental">Fundamental Types</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt02ch04s02.html">Numeric Properties</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt02ch04s03.html">NULL</a></span></dt></dl></dd><dt><span class="chapter"><a href="manual/dynamic_memory.html">5. Dynamic Memory</a></span></dt><dt><span class="chapter"><a href="manual/termination.html">6. Termination</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/termination.html#support.termination.handlers">Termination Handlers</a></span></dt><dt><span class="sect1"><a href="manual/verbose_termination.html">Verbose Terminate Handler</a></span></dt></dl></dd></dl></dd><dt><span class="part"><a href="manual/diagnostics.html">III.
- Diagnostics
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="manual/exceptions.html">7. Exceptions</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/exceptions.html#manual.diagnostics.exceptions.hierarchy">Exception Classes</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt03ch07s02.html">Adding Data to Exceptions</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt03ch07s03.html">Cancellation</a></span></dt></dl></dd><dt><span class="chapter"><a href="manual/bk01pt03ch08.html">8. Concept Checking</a></span></dt></dl></dd><dt><span class="part"><a href="manual/utilities.html">IV.
- Utilities
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="manual/functors.html">9. Functors</a></span></dt><dt><span class="chapter"><a href="manual/pairs.html">10. Pairs</a></span></dt><dt><span class="chapter"><a href="manual/memory.html">11. Memory</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/memory.html#manual.util.memory.allocator">Allocators</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/memory.html#allocator.req">Requirements</a></span></dt><dt><span class="sect2"><a href="manual/memory.html#allocator.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="manual/memory.html#allocator.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="manual/memory.html#allocator.using">Using a Specific Allocator</a></span></dt><dt><span class="sect2"><a href="manual/memory.html#allocator.custom">Custom Allocators</a></span></dt><dt><span class="sect2"><a href="manual/memory.html#allocator.ext">Extension Allocators</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/auto_ptr.html">auto_ptr</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/auto_ptr.html#auto_ptr.limitations">Limitations</a></span></dt><dt><span class="sect2"><a href="manual/auto_ptr.html#auto_ptr.using">Use in Containers</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/shared_ptr.html">shared_ptr</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/shared_ptr.html#shared_ptr.req">Requirements</a></span></dt><dt><span class="sect2"><a href="manual/shared_ptr.html#shared_ptr.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="manual/shared_ptr.html#shared_ptr.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="manual/shared_ptr.html#shared_ptr.using">Use</a></span></dt><dt><span class="sect2"><a href="manual/shared_ptr.html#shared_ptr.ack">Acknowledgments</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="manual/traits.html">12. Traits</a></span></dt></dl></dd><dt><span class="part"><a href="manual/strings.html">V.
- Strings
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="manual/bk01pt05ch13.html">13. String Classes</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/bk01pt05ch13.html#strings.string.simple">Simple Transformations</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt05ch13s02.html">Case Sensitivity</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt05ch13s03.html">Arbitrary Character Types</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt05ch13s04.html">Tokenizing</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt05ch13s05.html">Shrink to Fit</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt05ch13s06.html">CString (MFC)</a></span></dt></dl></dd></dl></dd><dt><span class="part"><a href="manual/localization.html">VI.
- Localization
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="manual/locales.html">14. Locales</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/locales.html#manual.localization.locales.locale">locale</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/locales.html#locales.locale.req">Requirements</a></span></dt><dt><span class="sect2"><a href="manual/locales.html#locales.locale.design">Design</a></span></dt><dt><span class="sect2"><a href="manual/locales.html#locales.locale.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="manual/locales.html#locales.locale.future">Future</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="manual/facets.html">15. Facets aka Categories</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/facets.html#manual.localization.facet.ctype">ctype</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/facets.html#facet.ctype.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="manual/facets.html#facet.ctype.future">Future</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/codecvt.html">codecvt</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/codecvt.html#facet.codecvt.req">Requirements</a></span></dt><dt><span class="sect2"><a href="manual/codecvt.html#facet.codecvt.design">Design</a></span></dt><dt><span class="sect2"><a href="manual/codecvt.html#facet.codecvt.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="manual/codecvt.html#facet.codecvt.use">Use</a></span></dt><dt><span class="sect2"><a href="manual/codecvt.html#facet.codecvt.future">Future</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/messages.html">messages</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/messages.html#facet.messages.req">Requirements</a></span></dt><dt><span class="sect2"><a href="manual/messages.html#facet.messages.design">Design</a></span></dt><dt><span class="sect2"><a href="manual/messages.html#facet.messages.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="manual/messages.html#facet.messages.use">Use</a></span></dt><dt><span class="sect2"><a href="manual/messages.html#facet.messages.future">Future</a></span></dt></dl></dd></dl></dd></dl></dd><dt><span class="part"><a href="manual/containers.html">VII.
- Containers
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="manual/sequences.html">16. Sequences</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/sequences.html#containers.sequences.list">list</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/sequences.html#sequences.list.size">list::size() is O(n)</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/vector.html">vector</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/vector.html#sequences.vector.management">Space Overhead Management</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="manual/associative.html">17. Associative</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/associative.html#containers.associative.insert_hints">Insertion Hints</a></span></dt><dt><span class="sect1"><a href="manual/bitset.html">bitset</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/bitset.html#associative.bitset.size_variable">Size Variable</a></span></dt><dt><span class="sect2"><a href="manual/bitset.html#associative.bitset.type_string">Type String</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="manual/containers_and_c.html">18. Interacting with C</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/containers_and_c.html#containers.c.vs_array">Containers vs. Arrays</a></span></dt></dl></dd></dl></dd><dt><span class="part"><a href="manual/iterators.html">VIII.
- Iterators
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="manual/bk01pt08ch19.html">19. Predefined</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/bk01pt08ch19.html#iterators.predefined.vs_pointers">Iterators vs. Pointers</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt08ch19s02.html">One Past the End</a></span></dt></dl></dd></dl></dd><dt><span class="part"><a href="manual/algorithms.html">IX.
- Algorithms
-
-</a></span></dt><dd><dl><dt><span class="preface"><a href="manual/bk01pt09pr02.html"></a></span></dt><dt><span class="chapter"><a href="manual/bk01pt09ch20.html">20. Mutating</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/bk01pt09ch20.html#algorithms.mutating.swap">swap</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/bk01pt09ch20.html#algorithms.swap.specializations">Specializations</a></span></dt></dl></dd></dl></dd></dl></dd><dt><span class="part"><a href="manual/numerics.html">X.
- Numerics
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="manual/complex.html">21. Complex</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/complex.html#numerics.complex.processing">complex Processing</a></span></dt></dl></dd><dt><span class="chapter"><a href="manual/generalized_numeric_operations.html">22. Generalized Operations</a></span></dt><dt><span class="chapter"><a href="manual/numerics_and_c.html">23. Interacting with C</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/numerics_and_c.html#numerics.c.array">Numerics vs. Arrays</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt10ch23s02.html">C99</a></span></dt></dl></dd></dl></dd><dt><span class="part"><a href="manual/io.html">XI.
- Input and Output
-
-</a></span></dt><dd><dl><dt><span class="chapter"><a href="manual/iostream_objects.html">24. Iostream Objects</a></span></dt><dt><span class="chapter"><a href="manual/streambufs.html">25. Stream Buffers</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/streambufs.html#io.streambuf.derived">Derived streambuf Classes</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt11ch25s02.html">Buffering</a></span></dt></dl></dd><dt><span class="chapter"><a href="manual/stringstreams.html">26. Memory Based Streams</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/stringstreams.html#manual.io.memstreams.compat">Compatibility With strstream</a></span></dt></dl></dd><dt><span class="chapter"><a href="manual/fstreams.html">27. File Based Streams</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/fstreams.html#manual.io.filestreams.copying_a_file">Copying a File</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt11ch27s02.html">Binary Input and Output</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt11ch27s03.html">More Binary Input and Output</a></span></dt></dl></dd><dt><span class="chapter"><a href="manual/io_and_c.html">28. Interacting with C</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/io_and_c.html#manual.io.c.FILE">Using FILE* and file descriptors</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt11ch28s02.html">Performance</a></span></dt></dl></dd></dl></dd><dt><span class="part"><a href="manual/extensions.html">XII.
- Extensions
-
-</a></span></dt><dd><dl><dt><span class="preface"><a href="manual/bk01pt12pr03.html"></a></span></dt><dt><span class="chapter"><a href="manual/ext_compile_checks.html">29. Compile Time Checks</a></span></dt><dt><span class="chapter"><a href="manual/debug_mode.html">30. Debug Mode</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/debug_mode.html#manual.ext.debug_mode.intro">Intro</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt12ch30s02.html">Semantics</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt12ch30s03.html">Using</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/bk01pt12ch30s03.html#debug_mode.using.mode">Using the Debug Mode</a></span></dt><dt><span class="sect2"><a href="manual/bk01pt12ch30s03.html#debug_mode.using.specific">Using a Specific Debug Container</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/bk01pt12ch30s04.html">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/bk01pt12ch30s04.html#manual.ext.debug_mode.design.goals">Goals</a></span></dt><dt><span class="sect2"><a href="manual/bk01pt12ch30s04.html#manual.ext.debug_mode.design.methods">Methods</a></span></dt><dt><span class="sect2"><a href="manual/bk01pt12ch30s04.html#manual.ext.debug_mode.design.other">Other Implementations</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="manual/parallel_mode.html">31. Parallel Mode</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/parallel_mode.html#manual.ext.parallel_mode.intro">Intro</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt12ch31s02.html">Semantics</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt12ch31s03.html">Using</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/bk01pt12ch31s03.html#parallel_mode.using.prereq_flags">Prerequisite Compiler Flags</a></span></dt><dt><span class="sect2"><a href="manual/bk01pt12ch31s03.html#parallel_mode.using.parallel_mode">Using Parallel Mode</a></span></dt><dt><span class="sect2"><a href="manual/bk01pt12ch31s03.html#parallel_mode.using.specific">Using Specific Parallel Components</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/bk01pt12ch31s04.html">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/bk01pt12ch31s04.html#manual.ext.parallel_mode.design.intro">Interface Basics</a></span></dt><dt><span class="sect2"><a href="manual/bk01pt12ch31s04.html#manual.ext.parallel_mode.design.tuning">Configuration and Tuning</a></span></dt><dt><span class="sect2"><a href="manual/bk01pt12ch31s04.html#manual.ext.parallel_mode.design.impl">Implementation Namespaces</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/bk01pt12ch31s05.html">Testing</a></span></dt><dt><span class="bibliography"><a href="manual/parallel_mode.html#parallel_mode.biblio">Bibliography</a></span></dt></dl></dd><dt><span class="chapter"><a href="manual/ext_allocators.html">32. Allocators</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/ext_allocators.html#manual.ext.allocator.mt">mt_allocator</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/ext_allocators.html#allocator.mt.intro">Intro</a></span></dt><dt><span class="sect2"><a href="manual/ext_allocators.html#allocator.mt.design_issues">Design Issues</a></span></dt><dt><span class="sect2"><a href="manual/ext_allocators.html#allocator.mt.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="manual/ext_allocators.html#allocator.mt.example_single">Single Thread Example</a></span></dt><dt><span class="sect2"><a href="manual/ext_allocators.html#allocator.mt.example_multi">Multiple Thread Example</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/bitmap_allocator.html">bitmap_allocator</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/bitmap_allocator.html#allocator.bitmap.design">Design</a></span></dt><dt><span class="sect2"><a href="manual/bitmap_allocator.html#allocator.bitmap.impl">Implementation</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="manual/ext_containers.html">33. Containers</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/ext_containers.html#manual.ext.containers.pbds">Policy Based Data Structures</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt12ch33s02.html">HP/SGI</a></span></dt><dt><span class="sect1"><a href="manual/bk01pt12ch33s03.html">Deprecated HP/SGI</a></span></dt></dl></dd><dt><span class="chapter"><a href="manual/ext_utilities.html">34. Utilities</a></span></dt><dt><span class="chapter"><a href="manual/ext_algorithms.html">35. Algorithms</a></span></dt><dt><span class="chapter"><a href="manual/ext_numerics.html">36. Numerics</a></span></dt><dt><span class="chapter"><a href="manual/ext_iterators.html">37. Iterators</a></span></dt><dt><span class="chapter"><a href="manual/ext_io.html">38. Input and Output</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/ext_io.html#manual.ext.io.filebuf_derived">Derived filebufs</a></span></dt></dl></dd><dt><span class="chapter"><a href="manual/ext_demangling.html">39. Demangling</a></span></dt><dt><span class="chapter"><a href="manual/ext_concurrency.html">40. Concurrency</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/ext_concurrency.html#manual.ext.concurrency.design">Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/ext_concurrency.html#manual.ext.concurrency.design.threads">Interface to Locks and Mutexes</a></span></dt><dt><span class="sect2"><a href="manual/ext_concurrency.html#manual.ext.concurrency.design.atomics">Interface to Atomic Functions</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/bk01pt12ch40s02.html">Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/bk01pt12ch40s02.html#manual.ext.concurrency.impl.atomic_fallbacks">Using Builtin Atomic Functions</a></span></dt><dt><span class="sect2"><a href="manual/bk01pt12ch40s02.html#manual.ext.concurrency.impl.thread">Thread Abstraction</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/bk01pt12ch40s03.html">Use</a></span></dt></dl></dd></dl></dd><dt><span class="appendix"><a href="manual/appendix_contributing.html">A.
- Contributing
-
-</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/appendix_contributing.html#contrib.list">Contributor Checklist</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/appendix_contributing.html#list.reading">Reading</a></span></dt><dt><span class="sect2"><a href="manual/appendix_contributing.html#list.copyright">Assignment</a></span></dt><dt><span class="sect2"><a href="manual/appendix_contributing.html#list.getting">Getting Sources</a></span></dt><dt><span class="sect2"><a href="manual/appendix_contributing.html#list.patches">Submitting Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/source_organization.html">Directory Layout and Source Conventions</a></span></dt><dt><span class="sect1"><a href="manual/source_code_style.html">Coding Style</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/source_code_style.html#coding_style.bad_identifiers">Bad Identifiers</a></span></dt><dt><span class="sect2"><a href="manual/source_code_style.html#coding_style.example">By Example</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/documentation_style.html">Documentation Style</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/documentation_style.html#doc_style.doxygen">Doxygen</a></span></dt><dt><span class="sect2"><a href="manual/documentation_style.html#doc_style.docbook">Docbook</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/source_design_notes.html">Design Notes</a></span></dt></dl></dd><dt><span class="appendix"><a href="manual/appendix_porting.html">B.
- Porting and Maintenance
-
-</a></span></dt><dd><dl><dt><span class="sect1"><a href="manual/appendix_porting.html#appendix.porting.build_hacking">Configure and Build Hacking</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/appendix_porting.html#build_hacking.prereq">Prerequisites</a></span></dt><dt><span class="sect2"><a href="manual/appendix_porting.html#build_hacking.map">Overview: What Comes from Where</a></span></dt><dt><span class="sect2"><a href="manual/appendix_porting.html#build_hacking.scripts">Storing Information in non-AC files (like configure.host)</a></span></dt><dt><span class="sect2"><a href="manual/appendix_porting.html#build_hacking.conventions">Coding and Commenting Conventions</a></span></dt><dt><span class="sect2"><a href="manual/appendix_porting.html#build_hacking.acinclude">The acinclude.m4 layout</a></span></dt><dt><span class="sect2"><a href="manual/appendix_porting.html#build_hacking.enable">GLIBCXX_ENABLE, the --enable maker</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/internals.html">Porting to New Hardware or Operating Systems</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/internals.html#internals.os">Operating System</a></span></dt><dt><span class="sect2"><a href="manual/internals.html#internals.cpu">CPU</a></span></dt><dt><span class="sect2"><a href="manual/internals.html#internals.char_types">Character Types</a></span></dt><dt><span class="sect2"><a href="manual/internals.html#internals.thread_safety">Thread Safety</a></span></dt><dt><span class="sect2"><a href="manual/internals.html#internals.numeric_limits">Numeric Limits</a></span></dt><dt><span class="sect2"><a href="manual/internals.html#internals.libtool">Libtool</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/abi.html">ABI Policy and Guidelines</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/abi.html#abi.cxx_interface">The C++ Interface</a></span></dt><dt><span class="sect2"><a href="manual/abi.html#abi.versioning">Versioning</a></span></dt><dt><span class="sect2"><a href="manual/abi.html#abi.changes_allowed">Allowed Changes</a></span></dt><dt><span class="sect2"><a href="manual/abi.html#abi.changes_no">Prohibited Changes</a></span></dt><dt><span class="sect2"><a href="manual/abi.html#abi.impl">Implementation</a></span></dt><dt><span class="sect2"><a href="manual/abi.html#abi.testing">Testing</a></span></dt><dt><span class="sect2"><a href="manual/abi.html#abi.issues">Outstanding Issues</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/api.html">API Evolution and Deprecation History</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/api.html#api.rel_300">3.0</a></span></dt><dt><span class="sect2"><a href="manual/api.html#api.rel_310">3.1</a></span></dt><dt><span class="sect2"><a href="manual/api.html#api.rel_320">3.2</a></span></dt><dt><span class="sect2"><a href="manual/api.html#api.rel_330">3.3</a></span></dt><dt><span class="sect2"><a href="manual/api.html#api.rel_340">3.4</a></span></dt><dt><span class="sect2"><a href="manual/api.html#api.rel_400">4.0</a></span></dt><dt><span class="sect2"><a href="manual/api.html#api.rel_410">4.1</a></span></dt><dt><span class="sect2"><a href="manual/api.html#api.rel_420">4.2</a></span></dt><dt><span class="sect2"><a href="manual/api.html#api.rel_430">4.3</a></span></dt></dl></dd><dt><span class="sect1"><a href="manual/backwards.html">Backwards Compatibility</a></span></dt><dd><dl><dt><span class="sect2"><a href="manual/backwards.html#backwards.first">First</a></span></dt><dt><span class="sect2"><a href="manual/backwards.html#backwards.second">Second</a></span></dt><dt><span class="sect2"><a href="manual/backwards.html#backwards.third">Third</a></span></dt></dl></dd></dl></dd><dt><span class="appendix"><a href="manual/appendix_free.html">C.
- Free Software Needs Free Documentation
-
-</a></span></dt><dt><span class="appendix"><a href="manual/appendix_gpl.html">D.
- GNU General Public License version 3
- </a></span></dt><dt><span class="appendix"><a href="manual/appendix_gfdl.html">E. GNU Free Documentation License</a></span></dt><dt><span class="index"><a href="manual/bk01ix01.html">Index</a></span></dt></dl></dd><dt><span class="book"><a href="bk02.html"></a></span></dt><dd><dl><dt><span class="article"><a href="api.html">API and Source Level Documentation</a></span></dt></dl></dd><dt><span class="book"><a href="bk03.html"></a></span></dt><dd><dl><dt><span class="article"><a href="faq.html">Frequently Asked Questions</a></span></dt></dl></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="manual/spine.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"> </td><td width="40%" align="right" valign="top"> The GNU C++ Library</td></tr></table></div></body></html>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 07:37:50 +0000