- Boost - lists.boost.org

Boost inspection notification (2007-03-20/RC_1_34_0) *LC*
by Rene Rivera 20 Mar '07

20 Mar '07

Boost Inspection Report Run Date: 16:06:08 UTC, Tuesday 20 March 2007 An inspection program <http://www.boost.org/tools/inspect/index.html> checks each file in the current Boost CVS for various problems, generating this as output. Problems detected include tabs in files, missing copyrights, broken URL's, and similar misdemeanors. Totals: 11447 files scanned 908 directories scanned (including root) 1053 problems reported Problem counts: 654 files missing Boost license info or having wrong reference text 399 files missing copyright notice Summary: any (1) archive (1) build (68) concept_check (22) conversion (5) doc (1) filesystem (2) function (1) graph (1) inspect (1) integer (9) lambda (10) libs (6) logic (2) math (1) more (13) mpl (419) multi_array (13) numeric (188) optional (1) people (4) program_options (35) property_map (15) ptr_container (8) python (6) rational (5) regex (4) regression (118) release (2) serialization (16) signals (2) smart_ptr (8) test (3) timer (1) tr1 (2) tuple (5) utility (12) variant (42) Details: *L* missing Boost license info, or wrong reference text *C* missing copyright notice |any| libs/any/doc/ any.xml: *L* |archive| boost/archive/detail/ utf8_codecvt_facet.hpp: *L* |build| tools/build/v2/build/ build-request.jam: *L* modifiers.jam: *L* tools/build/v2/doc/ Jamfile.v2: *C* *L* tools/build/v2/doc/src/ advanced.xml: *C* *L* architecture.xml: *C* *L* catalog.xml: *C* *L* extending.xml: *C* *L* faq.xml: *C* *L* fragments.xml: *C* *L* howto.xml: *C* *L* install.xml: *C* *L* recipes.xml: *C* *L* reference.xml: *C* *L* standalone.xml: *C* *L* tutorial.xml: *C* *L* userman.xml: *C* *L* tools/build/v2/example/generate/ REAME.txt: *C* *L* a.cpp: *C* *L* tools/build/v2/example/generator/ README.txt: *C* *L* soap.jam: *C* *L* tools/build/v2/example/python_modules/ python_helpers.jam: *C* *L* python_helpers.py: *C* *L* tools/build/v2/test/ abs_workdir.py: *C* *L* dependency_property.py: *L* dependency_test.py: *C* *L* direct_request_test.py: *C* *L* dll_path.py: *L* double_loading.py: *L* duplicate.py: *L* echo_args.jam: *C* *L* empty.jam: *C* *L* expansion.py: *L* explicit.py: *L* gcc_runtime.py: *L* tools/build/v2/test/project-test3/lib3/ Jamfile: *C* *L* tools/build/v2/test/ readme.txt: *C* *L* svn_tree.py: *L* tag.py: *L* test_system.html: *L* tools/build/v2/tools/ sun.jam: *L* xsltproc.jam: *L* |concept_check| libs/concept_check/ bibliography.htm: *L* concept_check.htm: *L* concept_covering.htm: *L* creating_concepts.htm: *L* libs/concept_check/doc/ Jamfile.v2: *C* *L* libs/concept_check/doc/reference/ Assignable.xml: *L* BidirectionalIterator.xml: *L* CopyConstructible.xml: *L* DefaultConstructible.xml: *L* EqualityComparable.xml: *L* ForwardIterator.xml: *L* InputIterator.xml: *L* LessThanComparable.xml: *L* OutputIterator.xml: *L* RandomAccessIterator.xml: *L* SignedInteger.xml: *L* concepts.xml: *L* libs/concept_check/ implementation.htm: *L* prog_with_concepts.htm: *L* reference.htm: *L* using_concept_check.htm: *L* |conversion| libs/conversion/ cast.htm: *L* index.html: *C* *L* lexical_cast.htm: *L* libs/conversion/test/ Jamfile.v2: *L* |doc| doc/html/ docutils.css: *L* |filesystem| libs/filesystem/doc/ tr2_proposal.html: *L* libs/filesystem/src/ utf8_codecvt_facet.hpp: *L* |function| boost/function/detail/ gen_maybe_include.pl: *L* |graph| libs/graph/doc/ lengauer_tarjan_dominator.htm: *L* |inspect| tools/inspect/build/ Jamfile.v2: *L* |integer| libs/integer/ cstdint.htm: *C* *L* libs/integer/doc/ integer_mask.html: *L* static_min_max.html: *L* libs/integer/ index.html: *C* *L* integer.htm: *L* integer_traits.html: *C* *L* |lambda| libs/lambda/doc/ Jamfile.v2: *C* *L* libs/lambda/doc/detail/ README: *C* *L* lambda_doc.xsl: *C* *L* lambda_doc_chunks.xsl: *C* *L* libs/lambda/test/ Makefile: *C* *L* |libs| libs/ expected_results.xml: *C* *L* maintainers.txt: *C* *L* platform_maintainers.txt: *C* *L* |logic| libs/logic/doc/ Jamfile.v2: *C* *L* |math| boost/math/ common_factor_rt.hpp: *L* |more| more/ error_handling.html: *L* generic_exception_safety.html: *C* *L* generic_programming.html: *L* getting_started.rst: *C* *L* moderators.html: *C* regression.html: *C* *L* report-apr-2006.html: *C* *L* report-jan-2006.html: *C* *L* |mpl| libs/mpl/doc/src/refmanual/ ASSERT.rst: *C* *L* ASSERT_MSG.rst: *C* *L* ASSERT_NOT.rst: *C* *L* ASSERT_RELATION.rst: *C* *L* AUX_LAMBDA_SUPPORT.rst: *C* *L* Acknowledgements.rst: *C* *L* Algorithms-Iteration.rst: *C* *L* Algorithms-Querying.rst: *C* *L* Algorithms-Runtime.rst: *C* *L* Algorithms-Transformation.rst: *C* *L* Algorithms.rst: *C* *L* AssociativeSequence.rst: *C* *L* BackExtensibleSequence.rst: *C* *L* BidirectionalIterator.rst: *C* *L* BidirectionalSequence.rst: *C* *L* CFG_NO_HAS_XXX.rst: *C* *L* CFG_NO_PREPROCESSED.rst: *C* *L* Categorized.rst: *C* *L* Data.rst: *C* *L* ExtensibleAssociativeSeq.rst: *C* *L* ExtensibleSequence.rst: *C* *L* ForwardIterator.rst: *C* *L* ForwardSequence.rst: *C* *L* FrontExtensibleSequence.rst: *C* *L* HAS_XXX_TRAIT_DEF.rst: *C* *L* HAS_XXX_TRAIT_NAMED_DEF.rst: *C* *L* Inserter.rst: *C* *L* IntegralConstant.rst: *C* *L* IntegralSequenceWrapper.rst: *C* *L* Iterators-Concepts.rst: *C* *L* Iterators-Metafunctions.rst: *C* *L* Iterators.rst: *C* *L* LIMIT_LIST_SIZE.rst: *C* *L* LIMIT_MAP_SIZE.rst: *C* *L* LIMIT_METAFUNCTION_ARITY.rst: *C* *L* LIMIT_SET_SIZE.rst: *C* *L* LIMIT_UNROLLING.rst: *C* *L* LIMIT_VECTOR_SIZE.rst: *C* *L* LambdaExpression.rst: *C* *L* Macros-Asserts.rst: *C* *L* Macros-Configuration.rst: *C* *L* Macros.rst: *C* *L* Metafunction.rst: *C* *L* MetafunctionClass.rst: *C* *L* Metafunctions-Arithmetic.rst: *C* *L* Metafunctions-Bitwise.rst: *C* *L* Metafunctions-Comparisons.rst: *C* *L* Metafunctions-Composition.rst: *C* *L* Metafunctions-Conditional.rst: *C* *L* Metafunctions-Invocation.rst: *C* *L* Metafunctions-Logical.rst: *C* *L* Metafunctions-Trivial.rst: *C* *L* Metafunctions-Type.rst: *C* *L* Metafunctions.rst: *C* *L* NumericMetafunction.rst: *C* *L* PlaceholderExpression.rst: *C* *L* Placeholders.rst: *C* *L* RandomAccessIterator.rst: *C* *L* RandomAccessSequence.rst: *C* *L* ReversibleAlgorithm.rst: *C* *L* Sequences-Classes.rst: *C* *L* Sequences-Concepts.rst: *C* *L* Sequences-Intrinsic.rst: *C* *L* Sequences-Views.rst: *C* *L* Sequences.rst: *C* *L* TagDispatchedMetafunction.rst: *C* *L* TrivialMetafunction.rst: *C* *L* VariadicSequence.rst: *C* *L* accumulate.rst: *C* *L* advance.rst: *C* *L* always.rst: *C* *L* and_.rst: *C* *L* apply.rst: *C* *L* apply_wrap.rst: *C* *L* arg.rst: *C* *L* at.rst: *C* *L* at_c.rst: *C* *L* back.rst: *C* *L* back_inserter.rst: *C* *L* begin.rst: *C* *L* bind.rst: *C* *L* bitand_.rst: *C* *L* bitor_.rst: *C* *L* bitxor_.rst: *C* *L* bool_.rst: *C* *L* clear.rst: *C* *L* contains.rst: *C* *L* copy.rst: *C* *L* copy_if.rst: *C* *L* count.rst: *C* *L* count_if.rst: *C* *L* deque.rst: *C* *L* deref.rst: *C* *L* distance.rst: *C* *L* divides.rst: *C* *L* empty.rst: *C* *L* empty_base.rst: *C* *L* empty_sequence.rst: *C* *L* end.rst: *C* *L* equal.rst: *C* *L* equal_to.rst: *C* *L* erase.rst: *C* *L* erase_key.rst: *C* *L* eval_if.rst: *C* *L* eval_if_c.rst: *C* *L* filter_view.rst: *C* *L* find.rst: *C* *L* find_if.rst: *C* *L* fold.rst: *C* *L* for_each.rst: *C* *L* front.rst: *C* *L* front_inserter.rst: *C* *L* greater.rst: *C* *L* greater_equal.rst: *C* *L* has_key.rst: *C* *L* identity.rst: *C* *L* if_.rst: *C* *L* if_c.rst: *C* *L* inherit.rst: *C* *L* inherit_linearly.rst: *C* *L* insert.rst: *C* *L* insert_range.rst: *C* *L* inserter_.rst: *C* *L* int_.rst: *C* *L* integral_c.rst: *C* *L* is_sequence.rst: *C* *L* iter_fold.rst: *C* *L* iter_fold_if.rst: *C* *L* iterator_category.rst: *C* *L* iterator_range.rst: *C* *L* joint_view.rst: *C* *L* key_type.rst: *C* *L* lambda.rst: *C* *L* less.rst: *C* *L* less_equal.rst: *C* *L* list.rst: *C* *L* list_c.rst: *C* *L* long_.rst: *C* *L* lower_bound.rst: *C* *L* map.rst: *C* *L* max.rst: *C* *L* max_element.rst: *C* *L* min.rst: *C* *L* min_element.rst: *C* *L* minus.rst: *C* *L* modulus.rst: *C* *L* multiplies.rst: *C* *L* negate.rst: *C* *L* next.rst: *C* *L* not_.rst: *C* *L* not_equal_to.rst: *C* *L* numeric_cast.rst: *C* *L* or_.rst: *C* *L* order.rst: *C* *L* pair.rst: *C* *L* partition.rst: *C* *L* plus.rst: *C* *L* pop_back.rst: *C* *L* pop_front.rst: *C* *L* preface.rst: *C* *L* prior.rst: *C* *L* protect.rst: *C* *L* push_back.rst: *C* *L* push_front.rst: *C* *L* quote.rst: *C* *L* range_c.rst: *C* *L* refmanual.py: *C* *L* remove.rst: *C* *L* remove_if.rst: *C* *L* replace.rst: *C* *L* replace_if.rst: *C* *L* reverse.rst: *C* *L* reverse_copy.rst: *C* *L* reverse_copy_if.rst: *C* *L* reverse_fold.rst: *C* *L* reverse_iter_fold.rst: *C* *L* reverse_partition.rst: *C* *L* reverse_remove.rst: *C* *L* reverse_remove_if.rst: *C* *L* reverse_replace.rst: *C* *L* reverse_replace_if.rst: *C* *L* reverse_stable_partition.rst: *C* *L* reverse_transform.rst: *C* *L* reverse_unique.rst: *C* *L* sequence_tag.rst: *C* *L* set.rst: *C* *L* set_c.rst: *C* *L* shift_left.rst: *C* *L* shift_right.rst: *C* *L* single_view.rst: *C* *L* size.rst: *C* *L* size_t.rst: *C* *L* sizeof_.rst: *C* *L* sort.rst: *C* *L* stable_partition.rst: *C* *L* terminology.rst: *C* *L* times.rst: *C* *L* transform.rst: *C* *L* transform_view.rst: *C* *L* unique.rst: *C* *L* unpack_args.rst: *C* *L* upper_bound.rst: *C* *L* value_type.rst: *C* *L* vector.rst: *C* *L* vector_c.rst: *C* *L* void_.rst: *C* *L* zip_view.rst: *C* *L* libs/mpl/doc/ style.css: *L* libs/mpl/example/fsm/ README.txt: *C* *L* libs/mpl/test/ Jamfile.v2: *C* *L* |multi_array| libs/multi_array/doc/ iterator_categories.html: *C* *L* reference.html: *L* libs/multi_array/doc/xml/ MultiArray.xml: *C* *L* const_multi_array_ref.xml: *C* *L* multi_array.xml: *C* *L* multi_array_ref.xml: *C* *L* reference.xml: *L* libs/multi_array/test/ Jamfile.v2: *L* |numeric| boost/numeric/ublas/ banded.hpp: *L* blas.hpp: *L* boost/numeric/ublas/detail/ concepts.hpp: *L* config.hpp: *L* definitions.hpp: *L* documentation.hpp: *L* duff.hpp: *L* iterator.hpp: *L* matrix_assign.hpp: *L* raw.hpp: *L* temporary.hpp: *L* vector_assign.hpp: *L* boost/numeric/ublas/ exception.hpp: *L* expression_types.hpp: *L* functional.hpp: *L* fwd.hpp: *L* hermitian.hpp: *L* io.hpp: *L* lu.hpp: *L* matrix.hpp: *L* matrix_expression.hpp: *L* matrix_proxy.hpp: *L* matrix_sparse.hpp: *L* operation.hpp: *L* operation_blocked.hpp: *L* operation_sparse.hpp: *L* storage.hpp: *L* storage_sparse.hpp: *L* symmetric.hpp: *L* traits.hpp: *L* triangular.hpp: *L* vector.hpp: *L* vector_expression.hpp: *L* vector_of_vector.hpp: *L* vector_proxy.hpp: *L* vector_sparse.hpp: *L* libs/numeric/conversion/test/ Jamfile.v2: *C* *L* test_helpers.cpp: *C* test_helpers2.cpp: *C* test_helpers3.cpp: *C* traits_test.cpp: *C* udt_example_0.cpp: *C* udt_support_test.cpp: *C* libs/numeric/ublas/bench1/ bench1.cpp: *L* bench1.hpp: *L* bench11.cpp: *L* bench12.cpp: *L* bench13.cpp: *L* libs/numeric/ublas/bench2/ bench2.cpp: *L* bench2.hpp: *L* bench21.cpp: *L* bench22.cpp: *L* bench23.cpp: *L* libs/numeric/ublas/bench3/ bench3.cpp: *L* bench3.hpp: *L* bench31.cpp: *L* bench32.cpp: *L* bench33.cpp: *L* libs/numeric/ublas/bench4/ bench4.cpp: *L* bench41.cpp: *L* bench42.cpp: *L* bench43.cpp: *L* libs/numeric/ublas/doc/ Release_notes.txt: *C* *L* array_adaptor.htm: *C* *L* banded.htm: *L* blas.htm: *L* bounded_array.htm: *C* *L* container_concept.htm: *L* doxygen.css: *C* *L* expression_concept.htm: *L* hermitian.htm: *L* index.htm: *L* iterator_concept.htm: *L* matrix.htm: *L* matrix_expression.htm: *L* matrix_proxy.htm: *L* matrix_sparse.htm: *L* operations_overview.htm: *L* overview.htm: *L* products.htm: *L* range.htm: *C* *L* libs/numeric/ublas/doc/samples/ banded_adaptor.cpp: *L* banded_matrix.cpp: *L* bounded_array.cpp: *L* compressed_matrix.cpp: *L* compressed_vector.cpp: *L* coordinate_matrix.cpp: *L* coordinate_vector.cpp: *L* hermitian_adaptor.cpp: *L* hermitian_matrix.cpp: *L* identity_matrix.cpp: *L* map_array.cpp: *L* mapped_matrix.cpp: *L* mapped_vector.cpp: *L* matrix.cpp: *L* matrix_binary.cpp: *L* matrix_binary_scalar.cpp: *L* matrix_column.cpp: *L* matrix_column_project.cpp: *L* matrix_matrix_binary.cpp: *L* matrix_matrix_solve.cpp: *L* matrix_range.cpp: *L* matrix_range_project.cpp: *L* matrix_row.cpp: *L* matrix_row_project.cpp: *L* matrix_slice.cpp: *L* matrix_slice_project.cpp: *L* matrix_unary.cpp: *L* matrix_vector_binary.cpp: *L* matrix_vector_range.cpp: *L* matrix_vector_slice.cpp: *L* matrix_vector_solve.cpp: *L* range.cpp: *L* slice.cpp: *L* symmetric_adaptor.cpp: *L* symmetric_matrix.cpp: *L* triangular_adaptor.cpp: *L* triangular_matrix.cpp: *L* unbounded_array.cpp: *L* unit_vector.cpp: *L* vector.cpp: *L* vector_binary.cpp: *L* vector_binary_outer.cpp: *L* vector_binary_redux.cpp: *L* vector_binary_scalar.cpp: *L* vector_range.cpp: *L* vector_range_project.cpp: *L* vector_slice.cpp: *L* vector_slice_project.cpp: *L* vector_unary.cpp: *L* vector_unary_redux.cpp: *L* zero_matrix.cpp: *L* zero_vector.cpp: *L* libs/numeric/ublas/doc/ storage_concept.htm: *C* *L* storage_sparse.htm: *L* symmetric.htm: *L* triangular.htm: *L* types_overview.htm: *L* ublas.css: *C* *L* unbounded_array.htm: *C* *L* vector.htm: *L* vector_expression.htm: *L* vector_proxy.htm: *L* vector_sparse.htm: *L* libs/numeric/ublas/test/ README: *C* *L* concepts.cpp: *L* test1.cpp: *L* test1.hpp: *L* test11.cpp: *L* test12.cpp: *L* test13.cpp: *L* test2.cpp: *L* test2.hpp: *L* test21.cpp: *L* test22.cpp: *L* test23.cpp: *L* test3.cpp: *L* test3.hpp: *L* test31.cpp: *L* test32.cpp: *L* test33.cpp: *L* test4.cpp: *L* test4.hpp: *L* test42.cpp: *L* test43.cpp: *L* test5.cpp: *L* test5.hpp: *L* test52.cpp: *L* test53.cpp: *L* test6.cpp: *L* test6.hpp: *L* test62.cpp: *L* test63.cpp: *L* test7.cpp: *L* test7.hpp: *L* test71.cpp: *L* test72.cpp: *L* test73.cpp: *L* |optional| libs/optional/test/ Jamfile.v2: *L* |people| people/ paul_moore.htm: *C* *L* vesa_karvonen.htm: *C* *L* |program_options| boost/program_options/detail/ utf8_codecvt_facet.hpp: *L* libs/program_options/build/ Jamfile.v2: *C* *L* libs/program_options/doc/ Jamfile.v2: *C* *L* acknowledgements.xml: *C* *L* changes.xml: *C* *L* design.xml: *C* *L* glossary.xml: *C* *L* howto.xml: *C* *L* overview.xml: *C* *L* post_review_plan.txt: *C* *L* todo.txt: *C* *L* tutorial.xml: *C* *L* libs/program_options/example/ Jamfile.v2: *C* *L* libs/program_options/test/ Jamfile.v2: *C* *L* program_options_size_test.py: *C* *L* ucs2.txt: *C* *L* utf8.txt: *C* *L* winmain.py: *C* *L* |property_map| libs/property_map/ LvaluePropertyMap.html: *L* ReadWritePropertyMap.html: *L* ReadablePropertyMap.html: *L* WritablePropertyMap.html: *L* associative_property_map.html: *L* const_assoc_property_map.html: *L* libs/property_map/doc/ dynamic_property_map.html: *C* *L* dynamic_property_map.rst: *C* *L* libs/property_map/ example2.cpp: *L* identity_property_map.html: *L* iterator_property_map.html: *L* property_map.html: *L* vector_property_map.html: *L* |ptr_container| libs/ptr_container/doc/ default.css: *L* intro.xml: *C* *L* ptr_container.xml: *L* libs/ptr_container/test/ Jamfile.v2: *C* *L* sequence_point.cpp: *C* *L* |python| libs/python/doc/ internals.html: *L* internals.rst: *L* libs/python/test/ operators_wrapper.cpp: *C* *L* operators_wrapper.py: *C* *L* |rational| boost/ rational.hpp: *L* libs/rational/ index.html: *L* rational.html: *L* rational_example.cpp: *L* rational_test.cpp: *L* |regex| libs/regex/build/ gcc-shared.mak: *C* *L* libs/regex/example/timer/ input_script.txt: *C* *L* |regression| tools/regression/build/ Jamfile.v2: *C* *L* tools/regression/detail/ tiny_xml_test.txt: *C* *L* tools/regression/ index.htm: *C* *L* run_tests.sh: *C* *L* tools/regression/test/test-cases/general/expected/ results.xml: *C* *L* tools/regression/test/test-cases/incremental/expected/ results.xml: *C* *L* tools/regression/test/ test.bat: *C* *L* tools/regression/xsl_reports/ boostbook_report.py: *C* *L* tools/regression/xsl_reports/db/ load.py: *C* *L* test-runs.xsd: *C* *L* tools/regression/xsl_reports/ empty_expected_results.xml: *C* *L* tools/regression/xsl_reports/runner/ __init__.py: *C* *L* default.css: *L* instructions.html: *L* instructions.rst: *C* *L* tools/regression/xsl_reports/test/ common.py: *C* *L* expected_results.xml: *C* *L* generate_test_results.py: *C* *L* generate_test_results_v1.py: *C* *L* restrict_to_library.xsl: *C* *L* run_notes_regression.py: *C* *L* run_v1.py: *C* *L* tools/regression/xsl_reports/test/test-components/ test.py: *C* *L* tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/ compile-fail.xml: *C* *L* completed.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/ compile-fail.xml: *C* *L* completed.xml: *C* *L* lib.xml: *C* *L* misfire.xml: *C* *L* no-run.xml: *C* *L* run_pyd.xml: *C* *L* test-case.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/ lib.xml: *L* misfire.xml: *C* *L* no-run.xml: *C* *L* run_pyd.xml: *C* *L* test-case.xml: *L* test-driver.xsl: *C* *L* tools/regression/xsl_reports/test/test-components/test_re_match/expected/ test_re_match.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_case_status/ a.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_case_status/expected/ a.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_case_status/ test-driver.xsl: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_structure/ a.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_structure/expected/ a.xml: *C* *L* tools/regression/xsl_reports/test/test-components/test_test_structure/ test-driver.xsl: *C* *L* tools/regression/xsl_reports/test/ test.py: *C* *L* test_boost_wide_report.py: *C* *L* tools/regression/xsl_reports/ test_results.xsd: *C* *L* tools/regression/xsl_reports/utils/ __init__.py: *C* *L* accept_args.py: *C* *L* char_translation_table.py: *C* *L* check_existance.py: *C* *L* checked_system.py: *C* *L* libxslt.py: *C* *L* log.py: *C* *L* makedirs.py: *C* *L* send_mail.py: *C* *L* sourceforge.py: *C* *L* tar.py: *C* *L* zip.py: *C* *L* tools/regression/xsl_reports/xsl/v2/ expected_to_1_33_format.xsl: *C* *L* |release| tools/release/ utils.py: *C* *L* |serialization| libs/serialization/doc/ style.css: *C* *L* libs/serialization/example/ demo_output.txt: *C* *L* demo_save.xml: *C* *L* demofile.txt: *C* *L* libs/serialization/test/ run_archive_test.bat: *C* *L* runtest.bat: *C* *L* runtest.sh: *C* *L* libs/serialization/vc7ide/ readme.txt: *C* *L* |signals| libs/signals/doc/ tutorial.xml: *C* *L* |smart_ptr| libs/smart_ptr/ compatibility.htm: *L* scoped_array.htm: *L* scoped_ptr.htm: *L* shared_array.htm: *L* shared_ptr.htm: *L* smart_ptr.htm: *L* smarttests.htm: *L* weak_ptr.htm: *L* |test| boost/test/utils/runtime/cla/detail/ argument_value_usage.hpp: *L* libs/test/test/auto-link-test/ run_bjam.bat: *C* *L* |timer| libs/timer/ timer.htm: *L* |tr1| boost/tr1/ tuple.hpp: *C* *L* |tuple| libs/tuple/doc/ design_decisions_rationale.html: *L* tuple_advanced_interface.html: *L* tuple_users_guide.html: *L* libs/tuple/test/ README: *C* *L* |utility| boost/ shared_container_iterator.hpp: *L* libs/utility/ OptionalPointee.html: *L* call_traits.htm: *L* compressed_pair.htm: *L* enable_if.html: *L* libs/utility/test/ Jamfile.v2: *L* libs/utility/ utility.htm: *L* value_init.htm: *L* value_init_test.cpp: *C* value_init_test_fail1.cpp: *C* value_init_test_fail2.cpp: *C* value_init_test_fail3.cpp: *C* |variant| libs/variant/doc/ Jamfile.v2: *C* *L* biblio.xml: *C* *L* design.xml: *C* *L* introduction.xml: *C* *L* misc.xml: *C* *L* libs/variant/doc/reference/ apply_visitor.xml: *C* *L* bad_visit.xml: *C* *L* concepts.xml: *C* *L* get.xml: *C* *L* recursive_variant.xml: *C* *L* recursive_wrapper.xml: *C* *L* reference.xml: *C* *L* static_visitor.xml: *C* *L* variant.xml: *C* *L* variant_fwd.xml: *C* *L* visitor_ptr.xml: *C* *L* libs/variant/doc/tutorial/ advanced.xml: *C* *L* basic.xml: *C* *L* tutorial.xml: *C* *L* libs/variant/doc/ variant.xml: *L* libs/variant/ index.html: *C* *L* libs/variant/test/ Jamfile.v2: *L*

1 0

[Report] 36 regressions on RC_1_34_0 (2007-03-20)
by Douglas Gregor 20 Mar '07

20 Mar '07

Boost Regression test failures Report time: 2007-03-20T02:23:14Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 36 failures in 4 libraries iostreams (6) optional (6) parameter (1) python (23) |iostreams| bzip2_test: msvc-7.1 msvc-8.0 gzip_test: msvc-7.1 msvc-8.0 zlib_test: msvc-7.1 msvc-8.0 |optional| optional_test: msvc-6.5 msvc-6.5 msvc-6.5_stlport4 msvc-7.0 optional_test_ref_fail2: msvc-7.1 msvc-8.0 |parameter| python_test: gcc-cygwin-3.4.4 |python| builtin_converters: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 import_: cw-9.4 gcc-mingw-3.4.2 gcc-mingw-3.4.5 intel-vc71-win-9.1 msvc-6.5 msvc-6.5 msvc-6.5_stlport4 msvc-7.0 msvc-7.1 msvc-7.1 msvc-7.1 msvc-7.1_stlport4 msvc-8.0 msvc-8.0 msvc-8.0 map_indexing_suite: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64

1 0

Extending Boost.Program_options
by Tom Bachmann 20 Mar '07

20 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, [I hope I'm on the right list..] I have been trying to extend Boost.Program_options, and I found this very hard. I'd like to let you know of the problems I'm experiancing. Basically, I am writing a relatively long-running program, with lots of options. I want to be able to change these options at run-time, for doing so, I want to create a "preferences" window or such, and (of course) I want to reuse the options description I already created to parse the command line and config file options. In my vision, things would work like this: po::options_description generic ("generic options"); generic.add_options () // e.g. --help, --version ... po::options_description sub1 ("options for module 1"); ... po::options_description sub2 ("options for module 2"); ... po::options_description preferences_options; preferences_options.add (sub1). add (sub2); ... // do normal parsing (command line, config file, ...) ... preferences_dialog pref (preferences_options); ... An open question is, when to propagate the options. My program works in some sort of main-loop, at the beginning of which I do pref.commit (vm); // save options, like store would do, but overwrite // and remember all options that changed if (pref.changed ("foo-option")) take care of this // e.g. reload something ... The preferences dialog should have one tab per option group (that is, one for "options for module 1" and one for "options for module 2"). Every of that tabs should display widgets to manipulate the respective options, that is, for every option, it's name, help information, some sort of input widget, maybe a reset button if there's a default value. Trying to implement all this, I encountered several problems. I'll try to make a list of things that have to be possible, and discuss all items in turn. 1 change the values of options in a variables_map 2 find out the type of an option 3 convert from an option value (stored in a Boost.Any) to some screen representation 4 find out what options in a po::options_description are members of what option groups 1 change the values of options in a variables_map The only way to do this (as far as I can see) is the private interface that the store function uses. I currently do const_cast<boost::program_options::variable_value&> (vm[opt -> long_name ()]).value () = val; which is neither clean nor complete (the internal reference to value_semantic is not updated, but this should not be necessary anyway, I think). The easiest fix would be to add a public interface to change the value of an option in a variables map, by making op[] return a non-const reference. I'm not sure if code should be added to call semantic -> notify automically. 2 find out the type of an option This is not strictly necessary, but I'd be nice to e.g show a checkbox for bool options, a spin button for numeric options, and an entry field for other options. I currently infer the type by querying the Boost.Any that holds the option, potentially after applying the default value. This is not foolproof, however, because it fails for options that have no default value and that have not been set before. 3 convert from an option value to some screen representation This is not strictly necessary either, but it'd be nice to show the user the current value of an option ;). This is some sort of "backward parse" and can be easily put into the value_semantic class. Afterall, this is already done, when converting the default value into a string. It is, however, not strictly something one would usually expect from the value_semantic class. Currently I take the type information I already have (see 2), cast to the respective type and then convert using Boost.Lexical_cast. This is quiet cumbersome, because I need to know every possible type in advance and (automatically) instantiate code for every such type and dynamically dispatch to the right code (this is the main reason I created the dispatcher mentioned in another mail of mine). 4 find out what options in a po::options_description are members of what option groups This is necessary to group the options in multiple tabs. Again, there are only private interfaces to access the information. All in all, I think the use of private (friend) interfaces overly restricts the reusability of Boost.Program_options. I don't know if what I try is in the scope of what should be possible, but I'm happy to discuss the problems I reported, both from the perspective of changing the library and from the perspective of changing my demands. And I have a (unrelated) suggestion for an improvement: add an auxiliary functor for validating. Often there are certain conditions imposed on the options, e.g. a numeric option has to be in some interval or such. This checking can be done once after parsing, but it'd be cleaner to directly incorporate it. One could encode all the information in the type, but that'd be ugly. Using Boost.Lambda, I could imagine a syntax like: po::checked_value<int> (_1 > 0 && _1 < 5) instead of po::value<checked_val<int, bounds_checker<int, 1, 4> > > () (where I overloaded validate for checked_val's to apply the functor encoded in the type). - -- - -ness- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF/BTYvD/ijq9JWhsRAsA4AKCBbigeh/fa3k1jEBKTmJ01JPz1FwCfQE7J 3CQIyp/rRMQb4VFnQqHR3Kg= =FRtW -----END PGP SIGNATURE-----

3 2

[futures] composite or
by Sohail Somani 20 Mar '07

20 Mar '07

Hi, I was looking at the futures implementation in the boost vault. It looks very promising, I must say. One of the open issues however is thread cancellation which I imagine will be important in the case of the "or" futures group. Has there been any progress on this front? One of the coolest things about boost libraries has been the gradual improvement of legacy C/C++ code by non-invasive means. I can't imagine solving this problem without invasive means (or traditionally undesirable means, i.e. something like thread->die()). I'm not saying that its non-invasive or nothing, but there are people smarter than me working on this problem! Thanks in advance, Sohail

15 91

Re: [boost] Extending Boost.Program_options
by Tom Bachmann 20 Mar '07

20 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> > And I have a (unrelated) suggestion for an improvement: add an auxiliary >> > functor for validating. Often there are certain conditions imposed on >> > the options, e.g. a numeric option has to be in some interval or such. >> > This checking can be done once after parsing, but it'd be cleaner to >> > directly incorporate it. One could encode all the information in the >> > type, but that'd be ugly. Using Boost.Lambda, I could imagine a syntax >> > like: >> > >> > po::checked_value<int> (_1 > 0 && _1 < 5) >> > >> > instead of >> > >> > po::value<checked_val<int, bounds_checker<int, 1, 4> > > () > > Sigh. This is on todo list, but I haven't had any time for that. > I forgot to mention that this is especially useful in my case, because then the UI can detect (some) wrong inputs and complain directly. I think one easy way to implement this would be to (1) pass a reference to value_semantic to the validation functions, (2) add a virtual is_correct function to value_semantic that defaults to accepting everything, (3) call value_semantic::is_correct in the validation functions, (4) subclass typed_value to hold a functor that is invoked upon overwritten is_correct, and (5) provide a checked_value function similar to value. (2), (4) and (5) are mostly trivial, and I'm happy to provide you a patch for that. (1) and (3) shouldn't be hard either, but require more invasive changes. - -- - -ness- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF/+KlvD/ijq9JWhsRAuOLAJoCWeSVBukRRP+02h2N0bjOxr1PqQCcCtfe B8HQ3EzCP/E6vghOHo0faLI= =pE/C -----END PGP SIGNATURE-----

1 0

Keeping track of affine frames
by Hugo Duncan 20 Mar '07

20 Mar '07

Hi, We recently wrote some code that did some computaional mechanics and had several bugs due to mixing frames of reference. Prompted by recent discussions of affine spaces, I have developed some simple classes for tracking different spaces, points and displacements at compile time. eg. struct frame1 {}; struct frame2 {}; typedef ublas::bounded_vector<double,3> vector; typedef math::point<vector, frame1> point; typedef math::displacement<vector, frame1> displacement; point p1(ublas::scalar_vector<double>(3,1.)); point p2(ublas::scalar_vector<double>(3,1.)); displacement d1(ublas::scalar_vector<double>(3,1.)); p2=p1+d1; d1=p1+d1; //fails p1=p1+p1; //fails vector p3(ublas::scalar_vector<double>(3,1.)); vector d2(ublas::scalar_vector<double>(3,1.)); math::point_ref<frame1>(p3)+=d1; math::point_ref<frame2>(p3)+=d1; // fails math::point_ref<frame1>(p3)+=math::displacement_ref<frame1>(d2); math::point_ref<frame2>(p3)+=math::displacement_ref<frame2>(d2); math::point_ref<frame1>(p3)+=math::displacement_ref<frame2>(d2); // fails The code is available in the math-geometry section of the boost vault at http://www.boost-consulting.com/vault/index.php?direction=0&order=&director… as affine-0.0.3.tar.gz Comments welcome on the utility of the approach and on the design are most welcome. Hugo

1 0

Re: [boost] Extending Boost.Program_options
by Tom Bachmann 20 Mar '07

20 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> > The easiest fix would be to add a public interface to change the value >> > of an option in a variables map, by making op[] return a non-const >> > reference. I'm not sure if code should be added to call semantic -> >> > notify automically. > > Yep, I guess we need non-const-returning[] for sure. We probably should > have variable_value overload operator=, and call semantic->notify. Yes, this sounds cleanest. > Do > you think disallowing assignements that change value type is OK? Say, > if you try to assign int to value of type double, you get exception. > This sounds sensible to me. >> > 2 find out the type of an option >> > >> > This is not strictly necessary, but I'd be nice to e.g show a checkbox >> > for bool options, a spin button for numeric options, and an entry field >> > for other options. I currently infer the type by querying the Boost.Any >> > that holds the option, potentially after applying the default value. >> > This is not foolproof, however, because it fails for options that have >> > no default value and that have not been set before. > > Technically speaking, the value_semantic base class does not require an > option to have any type at all. At the same time, in 100% of known cases > the type for an option is known. Perhaps I can either add 'type' method > to value_semantics that returns type_info* and may return NULL, or just > make it return type_info& and demand that all options have a fixed type. > Will either of those approaches work for you? > Either will work. >> > 3 convert from an option value to some screen representation > [...] > One another approach is make variable_value record original tokens it > was constructed from. This correlates with your point (1) above -- > perhaphs after UI was changed, value_semantics->parse should be called > to get new boost::any and the parsed tokens should be stored in variable_value. > Again, this sounds cleaner than my proposal. >> > 4 find out what options in a po::options_description are members of what >> > option groups >> > >> > This is necessary to group the options in multiple tabs. Again, there >> > are only private interfaces to access the information. > > The problem here is that when you add one options_description to > another options description, the original object is not retained, so > it's not simple to have "parent pointer". It might be possible to > have "parent group name" field in an option. Would that be too cumbersome > to construct UI hierarchy grouping options by string parent name? > Putting the parent string into every option sounds unnecessarily complicated too me (from a user perspective). What about making options_description manage map of views in the main options vector, that is, something like map<parent_string,vector<option*> >. With an adequate public interface, my problem would be solvable in a strightforward way. With the interface changes described, a clean options window implementation seems to be possible. - -- - -ness- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF/84JvD/ijq9JWhsRAqmgAJ9i28pXZH/iO7/73xCsjOB2b9MJtACeMNkp FYAYuTktzPcevz76exgZFWA= =F50V -----END PGP SIGNATURE-----

1 0

[sorting] What are the most complicated sorting problems?
by Sam Schetterer 20 Mar '07

20 Mar '07

Hi. Since people want the sorting library to have something that the standard library sorts do not offer, I would like to know the most complicated sorting situations that user have encountered (like sort by name, and then first three digits of phone number, and if the sum of the first three digits of the phone number is less than 10, sort by the second 4 digits of the phone number). I ask this because radixsort and radix quicksort are able to do those sorts, but I need input from users to add features. Also, even if you do not have any complicated sorts, ideas in general would help.

5 6

[regex] format_perl conundrum
by Eric Niebler 20 Mar '07

20 Mar '07

I have a question and a bug report regarding the format_perl flag. First the question ... I see that, when you specify format_perl, match_results::format() recognizes the escape sequences \l \L \u and \U, which do uppercasing or lowercasing. These are necessarily locale-dependent character transformations, but match_results does not have a Traits parameter. How should the transformations be done? I note that the basic_regex<> class template has a traits parameter, and that match_results<>::format() can only be called after a successful regex match. One reasonable approach is that match_results<> holds a (shared) pointer to the regex object's traits. It would have to be a polymorphic base pointer, since match_results can't know the exact type of the traits object at the time format() is called. That doesn't exactly work because the RegexTraits concept doesn't have toupper() and tolower() functions. I suggest adding them. This isn't only a problem for format_perl, strictly speaking. match_results::format() also needs to know how to turn characters into integers (eg. to parse format strings like "$1"). That is the reason for RegexTraits::value()'s existence, so match_results<>::format() should use it. (Incidentally, I just implemented all this in xpressive, so I can confirm that this strategy works. It incurs a virtual call for each tolower(), toupper(), and value(), but there doesn't seem to be any other way without changing the interface in a non-TR1 compatible way.) Finally, a bug report. Consider the following code: std::string str ("fOO bAr BaZ"); regex rx ("\\w+"); str = regex_replace( str, rx, "\\L\\u$&", format_perl ); std::cout << str << std::endl; This prints: FOO BAr BaZ However, the equivalent perl: $str= 'fOO bAr BaZ'; $str =~ s/\w+/\L\u$&/g; print "$str\n"; Prints this: Foo Bar Baz Looks like in boost::regex, the \u is stomping the \L rather than merely overriding it for the next character. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 3

Proposed Boost Exception updated
by Emil Dotchevski 20 Mar '07

20 Mar '07

Documentation, source code and tests available for online browsing here: http://www.revergestudios.com/boost-exception/boost-exception.htm Everything is also available as a single .zip file download: http://www.revergestudios.com/boost-exception/boost-exception.zip This update includes only a minor change in how boost::exception::what() deduces the string representation of objects stored in a boost::exception. See http://www.revergestudios.com/boost-exception/boost-exception.htm#logging for details. Comments/feedback much appreciated. Emil Dotchevski _________________________________________________________________ Watch free concerts with Pink, Rod Stewart, Oasis and more. Visit MSN Presents today. http://music.msn.com/presents?icid=ncmsnpresentstagline&ocid=T002MSN03A07001

1 0