- Boost - lists.boost.org

Boost inspection notification (2007-06-19/RC_1_34_0) *LC*
by Rene Rivera 19 Jun '07

19 Jun '07

Boost Inspection Report Run Date: 16:05:17 UTC, Tuesday 19 June 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: 11452 files scanned 909 directories scanned (including root) 1059 problems reported Problem counts: 661 files missing Boost license info or having wrong reference text 398 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 (417) multi_array (13) numeric (188) optional (1) people (4) program_options (35) property_map (15) ptr_container (8) python (14) 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* 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/doc/tutorial/doc/html/python/ embedding.html: *L* exception.html: *L* exposing.html: *L* functions.html: *L* hello.html: *L* iterators.html: *L* object.html: *L* techniques.html: *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] 0 regressions on RC_1_34_0 (2007-06-19)
by Douglas Gregor 19 Jun '07

19 Jun '07

Boost Regression test failures Report time: 2007-06-18T22:11:09Z 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… No failures! Yay!

1 0

Re: [boost] Request for consideration for my weak_ptr class
by Alex Burton 19 Jun '07

19 Jun '07

Scott wrote: > raw_ptr might be a better name, then. It's less than weak, since weak > pointers are actually quite intelligent, knowing whether or not > they're dangling. At the moment i think simple_ptr is best, raw_ptr would cause confusion when speaking of actual raw pointers and raw_ptrs. > >> It allows my code to be free of the * pointer notation. >> All pointers look the same, ie shared_ptr<Foo>, scoped_ptr<Foo>, >> weak_ptr<Foo> >> > Those smart pointers are all well-behaved, though. raw pointers are > not. a raw pointer is only not well behaved in that it may point to an object that may or may not need to be deleted at some time. A (now simple_ptr) shows that the programmer explicitly says that this pointer is only used for observing the pointed to object, and doesn't own or share it. > >> It can be used in many places a reference would be used. >> > You can't get the address of temporaries, so I don't understand where > you'd use it in place of references... Yes, references are important, I am not trying to replace them. >> In the above code, if vector<Foo> foos was changed to vector< >> shared_ptr<Foo> > the code will still work perfectly with out change. >> >> I find this really useful because often small structs become >> polymorphic classes (requiring shared_ptr) as code evolves. >> >> The vector example is the best, but even when returning a pointer >> to something like this it is good: >> >> if Bar mBar becomes scoped_ptr<Bar> mBar, the accessor still >> compiles. >> > For your vector example, have you considered starting with > vector<Foo>, then changing to ptr_vector<IFoo> later? I think that'll > get you the same effect, but it's much safer. Yes, i am not familiar with ptr_vector, but a quick look at it suggests that it would solve that problem. > > That constructor from a reference also looks like it'd be far too easy > to mistakenly return a pointer to a local variable. Yes the constructor from a reference would allow some dangerous things, and I wouldn't suggest a constructor like this was added to any of the boost smart pointer classes. The reason I think it may be permissible here is because the simple_ptr is explicitly non owning and therefore you need to make sure that the pointed to object exists just the same as a raw pointer. > I'm not convinced > that your method is much superior to returning a reference and, if the > member does become a pointer, just adding the * to dereference it in > the accessor. I'm not convinced by saving having to type this one * either, but it is the cumulative saving of quite a few changes like this that I find motivating. > > Probably not quite following just yet, Don't get this wrong - there isn't much to follow, this class does absolutely nothing functional. But it does Change the syntax of code - unifying pointer syntax in the presence of other smart pointer types Make code more explicit - by removing ambiguous raw pointers Save some work when things change - by doing the conversions for you with implicit constructors, which are not dangerous because the class is explictly a non owning pointer. Allow null pointer dereference check. Alex

1 0

Re: [boost] Request for consideration for my weak_ptr class
by Alex Burton 19 Jun '07

19 Jun '07

Marcus wrote: > Alex Burton wrote: >> I understand there would be a collision with boost::weak_ptr, >> which is used for special scenarios with shared_ptr as I understand. >> > Hm. checked_ptr, standard_ptr, regular_ptr, simple_ptr or just raw_ptr > might be better names, to avoid collisions? I agree with you. I've changed it to simple_ptr (standard_ptr, regular_ptr would be ok too), checked_ptr doesn't describe the true intent, and raw_ptr would cause confusion when speaking about actual raw pointers and instances raw_ptr. > > (The concept of a weak pointer or reference is quite common when > used in > garbage collection, as with boost::shared_ptr, so IMHO I would avoid > that in general for non-gc pointer types.) >> A fair comment would be that this class actually does nothing, >> that a normal pointer would do and this is true. >> However, I find it extremely useful, and would like it considered >> as an addition to boost. >> > Good initiative. However, there seems to be some orthogonal concepts > baked in here, and everyone might not want all of them at the same > time, > even if each one is useful on their own. Perhaps each concept could be > split up (via policy classes) so that one could define checks for any > pointer? The intent of the pointer is not just to check null dereferences. The check that currently throws an exception could be changed to do what scoped_ptr etc does, which is to do a debug assertion. >> It allows my code to be free of the * pointer notation. >> All pointers look the same, ie shared_ptr<Foo>, scoped_ptr<Foo>, >> weak_ptr<Foo> >> > Why is that desirable? It is desirable so that that the pointers look the same, this means that fewer mistakes when changing between pointer types as code changes. It is also desirable (at least for me) so that in my code I explicitly see the intent of the pointer. When (now simple_ptr) is used the programmers intent is to only look at the object pointed to, not to own it or share it. When a normal pointer is used, the intent is unclear. >> It throws an exception if it has been default constructed or set >> to 0, this could probably be a debug only behaviour for >> efficiency, but i leave it in release code. >> > I find the notion of a null ptr useful. How about just checking > that in > operator * and -> as other boost::ptr's. I do too (though never in production code, only in test code). The check is only made as you describe. > > Unless actually do want a nonnull_ptr, but that should be optional. > (boost::ahared_ptr's can be >> It can be used in many places a reference would be used. >> > I don't get this one. It's not a smart reference, a smart pointer? No it is just a non owning pointer. >> It includes constructors for many smart pointer types and from a >> reference to the class pointed to. >> > Useful. However, you might want to consider a unqualified > get_pointer() > call to allow for any smart pointer (including my secret one that I > won't show you :-). Also, less constructors. (as for get_pointer(), I > believe boost::bind and others uses it to get the raw-pointer from any > type, including references) Great suggestion, ive replaced all those constructors with template<class Y> simple_ptr(const Y & y) : p(get_pointer(y)) {} and added template<class T> inline T * get_pointer(simple_ptr<T> const & p) { return p.get(); } >> using namespace std; >> >> struct IFoo >> { >> }; >> >> struct Foo : IFoo >> { >> }; >> >> vector<Foo> foos; >> >> BOOST_FOREACH(weak_ptr<Foo> f,foos) >> { >> //do something with f-> >> } >> >> vector< weak_ptr<IFoo> > weakfoos; >> std::copy(foos.begin(),foos.end(),back_inserter(weakfoos)); >> >> In the above code, if vector<Foo> foos was changed to vector< >> shared_ptr<Foo> > the code will still work perfectly with out change. >> >> I find this really useful because often small structs become >> polymorphic classes (requiring shared_ptr) as code evolves. >> > Yup. I see where that could be useful. > > OTOH, the for_each could use an indirect_iterator-range instead, to > iterate over IFoo& instead. Yes but that would require a change to the code.

2 1

unable to link with stlport
by Tal Agmon 19 Jun '07

19 Jun '07

hi ppl. I'm using boost 1.34 w/ stlport version 5.1.3 on windows xp.sp2 compiler msvc8 stlport was build with _STLP_USE_BOOST_SUPPORT. it seems that after invoking bjam V2 03.1.13 using directions in getting started page. I have not seen any libs with ABI tag key 'p' generated. here is an example of pattern libs i got in the stage dir. boost_signals-vc80-mt-1_34.lib boost_signals-vc80-mt.lib boost_signals-vc80-mt-gd-1.34.lib boost_signals-vc80-mt-gd.lib but i don't have any of libs such as boost_signals-vc80-mt-gdp-1.34.lib boost_signals-vc80-mt-gdp.lib output msg: (one of many examples using stlport w/boost) STLport: Auto linking to stlportstld.5.1.lib 1>Generating Code... 1>Compiling manifest to resources... 1>Linking... 1>LINK : fatal error LNK1104: cannot open file 'libboost_signals-vc80-mt-gdp-1_34.lib' can anyone give me an insight here?

3 6

[1.34.1] Please Check Release Notes
by Thomas Witt 19 Jun '07

19 Jun '07

Hi, Those of you who want to have something mentioned in the 1.34.1 release notes have one more day to edit index.html on the branch. RC_1_34_0 will be completely frozen Tuesday 1pm PST. Thanks Thomas -- Thomas Witt witt(a)acm.org

1 0

Re: [boost] [rfc] I/O Library Design
by Jeremy Maitin-Shepard 18 Jun '07

18 Jun '07

Cédric Venet <cedric.venet(a)student.ecp.fr> writes: >> -> Hard formatting: printf/scanf are much easier to use and they don't >> >> need several hundred of function calls to do their job. The >> operator<< >> >> > I'd rather disagree with you here. Operator<< gives a great advantage >> of >> > extensibility which printf cannot offer. I can define my own classes >> That is not a real issue. You can easily provide a mechanism for >> supporting user-defined types on top of a printf/scanf-like interface, >> e.g. by specializing a template, or overloading some other function >> that >> is called by the implementation of the formatting system. So ease of >> supporting user-defined types is not an argument in favor of >> operator<<. > Supposing I want some function which take a formatting chain and an arbitrary > number of parameter to pass it to the new printf and then do something (usually, > add a prefix, a new line or throw an exception). How can I do the forwarding in > C++2003 (without defining x overload). Perhaps fusion provide some support for > this? Yes, to actually get the syntax printf(...), you would indeed need either a lot of overloads, or vararg template support. A lot of facilities in boost, such as bind, have the same limitation, though. > Motivation: > Template<class T... > > Void PrintAndThrow(const char* c, T... args) { > Cout.printf(c,args); > Throw somethings; > } > Another things is what would be the type of the format string: a const char* or > std::string? I'm not sure about this. It makes the most sense for the format string to be in the same encoding as the output text (which might likely be UTF-8 or UTF-16), so it is not clear what type would be used to represent such a string. There is also the issue that it is inconvenient to specify a string literal in C++ that is encoded in a particular encoding (the encoding used varies by compiler, platform, locale settings). > Which would need parsing each time (an no compile time checking) or > a complex type build by expression template (I am thinking about some proto DSL > here). It would require parsing each time, but provided that the syntax is reasonably simple, the parsing overhead may be very small. The lack of compile-time checking is annoying, although some compilers might provide it as a hack, and at least there can be runtime type checking, unlike with C printf. > It would be more complex and slower to compile, but it as some > advantage. I think that any sort of complex expression template framework would be totally out of the question, because the increase in compile-time would make the library so inconvenient to use that it would just not be worth using at all. > This problem don't existe with << since we treat one object at a time > which is the reason reordering is impossible and internationalization difficult. -- Jeremy Maitin-Shepard

2 2

[statechart] 1.34.0 compilation failures with GCC 4.1.2
by Douglas Gregor 18 Jun '07

18 Jun '07

We're getting some strange compilation failures in the Statechart library with GCC 4.1.2, which don't seem to show up in GCC 4.1.0 or 4.2.0. Could anyone take a look a these? They show up here: http://dart.resophonic.com/boost_1_34_0/Dashboard/Build? submissionid=415 - Doug

2 1

(Was: Boost Development Environment proposal)
by Henrik Sundberg 18 Jun '07

18 Jun '07

2007/6/4, troy d. straszheim <troy(a)resophonic.com>: > My workspace (CVS HEAD) contains some svn:externals that look like > this: > > iostreams https://svn.boost.org/svn/projects/iostreams/trunk > variant https://svn.boost.org/svn/projects/variant/trunk > date_time https://svn.boost.org/svn/projects/date_time/trunk > (etc) > > which means the code layout looks like that above. When I svn update, > each of those subdirectories are updated recursively. I can make one > commit across multiple projects. No, commits don't pass into externals. >From http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.externals: The support that exists for externals definitions in Subversion today can be a little misleading, though. First, an externals definition can only point to directories, not files. Second, the externals definition cannot point to relative paths (paths like ../../skins/myskin). Third, the working copies created via the externals definition support are still disconnected from the primary working copy (on whose versioned directories the svn:externals property was actually set). And Subversion still only truly operates on non-disjoint working copies. So, for example, if you want to commit changes that you've made in one or more of those external working copies, you must run svn commit explicitly on those working copies—committing on the primary working copy will not recurse into any external ones. /$

7 19

Re: [boost] [rfc] I/O Library Design
by Ion Gaztañaga 18 Jun '07

18 Jun '07

Cédric Venet wrote: >> bounces(a)lists.boost.org] De la part de Ion Gaztañaga >> >> -> Hard formatting: printf/scanf are much easier to use and they don't >> need several hundred of function calls to do their job. The operator<< >> overloading is also a problem if each call needs some internal locking. >> A formatting syntax that can minimize the locking needs would be a good >> choice. I would be really happy with a type-safe printf (variadic >> templates to the rescue). >> > > You can limit the need of locking call pretty easily, even with operator <<. > You just need to use a temporary object which unlock the mutex when > destroyed: Nice info. My point is that the interface makes locking harder and we need to do some (esoteric) tricks. Many times, the locking need is deep in the IO architecture and taking the lock outside to the user code to group several calls in a single lock leads to bigger critical sections -> more contention. IMHO, the design should minimize both locking calls and critical section size. My point is that comparing to printf, concatenating operator << (which means several chained functions instead of a single function call) makes things a bit harder. Anyway, I think your solution is nice and useful. Regards, Ion

1 0