November 2006 - Boost - lists.preview.boost.org

[proposal] Sequence container with O(log n) random access _and_ O(log n) insertion/removal (wherever)
by Martin Knoblauch Revuelta 02 Nov '06

02 Nov '06

- How about a sequence container (like a vector) with the advantage of logarithmic time insertion/removal at any point of the sequence? The disadvantage is that random access takes logarithmic time too (instead of the usual constant time random access of a vector). Here it is: http://sourceforge.net/projects/avl-array It is implemented with a tree, but it is _not_ a map. The 'position' of elements in avl_array are always natural numbers (0, 1, 2... up to size()-1). When an element is inserted/removed, it changes automatically the position of all elements after it in the sequence (in logarithmic time!). A simple experiment realized consisted in populating a container by inserting random numbers in random positions, and then removing numbers from random positions, showing the value of the last one for checking. In this test AVL Arrays completely outperform list, vector and deque. The test code and the results are in sourceforge too. Version 1.1 includes a new experimental feature that I call "Non-Proportional Sequence View". In the normal sequence, every element occupies a position of size 1. Additionally, elements can be viewed as a sequence where the 'width' of every element can be changed (in O(log n) time), being the position of every element the sum of the widths of all previous elements in the sequence. Negative widths are forbidden, but zero widths are valid. The type used for the width is a template parameter, so any class supporting some operators can be used, not only unsigned or double. I've tried to adapt it to the boost requirements, but I'm sure there's still a lot of things to change. If you are interested, please take a look at it, and tell me your opinion. Regards, Martin Knoblauch Revuelta Universidad de Alcala

4 11

[config] patch for config/compiler/hp_acc.hpp
by Boris Gubenko 02 Nov '06

02 Nov '06

Attached a small patch for hp_acc.hpp configuration header. It fixes all but one failure in parameter library (the remaining failure is python_test which is, most likely, some configuration problem with python). The tests would not compile with the old header because it defines BOOST_NO_TEMPLATE_TEMPLATES macro which is inappropriate for aCC6 compiler. The patch also fixes test failures in statechart library, this library now has zero failures. I also verified, that the patch does not introduce any regressions. I think, the changes are obvious, but I can comment, if necessary. The only question I can envision is: why inclusion of "common_edg.hpp" is conditionalized with '#if (__HP_aCC >= 61200)' and not with, say, '> 60000' ? After all, aCC6 is EDG-based compiler since day one. The reason is that before A.06.12, the compiler does not predefine __EDG__ and __EDG_VERSION__ macros. It was corrected in A.06.12. Since "common_edg.hpp" checks if __EDG_VERSION__ is defined, it cannot be included if a pre-A.06.12 compiler is used. Of course, I could use '#ifdef __EDG_VERSION__' condition, but I thought, that a specific compiler version in hp_acc.hpp header is more appropriate. Can the patch below be applied to both the HEAD and the RC 1.34 branch? Thanks, Boris Index: hp_acc.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/config/compiler/hp_acc.hpp,v retrieving revision 1.20 diff -r1.20 hp_acc.hpp 5a6 > // (C) Copyright Boris Gubenko 2006. 13a15,18 > #if (__HP_aCC >= 61200) > #include "boost/config/compiler/common_edg.hpp" > #endif > 30,31c35 < // This version check is way to high, but we don't know the right one to use: < #if (__HP_aCC < 60700) --- > #if (__HP_aCC < 60000) 62c66 < #if (__HP_aCC > 53800) --- > #if (__HP_aCC > 61300)

2 1

[program_options] Potential bug in options_description.cpp
by Stas Khirman 02 Nov '06

02 Nov '06

While reviewing diff of options_description.cpp rev 1.14 and 1.17 , I came across of potential bug in line 417: 417 : (line_length - indent) / 2) However, line_length already had been decrease by "indent" in line 332 ( introduced in rev 1.15) I assume that correction is: 417 : (line_length) / 2) Regards Stas Khirman

1 0

Boost regression notification (2006-10-31 [RC_1_34_0])
by Douglas Gregor 02 Nov '06

02 Nov '06

Boost Regression test failures Report time: 2006-10-31T11:56: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… 36 failures in 7 libraries date_time (1) iostreams (10) mpl (4) program_options (7) random (1) serialization (12) utility (1) |date_time| testgreg_serialize_xml: msvc-8.0 |iostreams| bzip2_test: msvc-7.1 msvc-8.0 example_test: vc-6_5-stlport file_descriptor_test: cw-9.4 finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 mapped_file_test: cw-9.4 zlib_test: msvc-7.1 msvc-8.0 |mpl| multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: cw-9.4 variable_map_test_dll: cw-9.4 winmain_dll: cw-9.4 |random| random_test: intel-linux-9.0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |utility| operators_test: gcc-3.4.5_linux_x86_64

3 2

[thread] Question about MT API C++0X N2094
by Roland Schwarz 01 Nov '06

01 Nov '06

I'd like to know the rationale behind mutex concept requiring explicit locking signatures. Are users of the library "allowed" to access them directly? If yes why? Isn't this redundant to locks? Not requiring them, but letting them be implementation defined will allow the implementor more freedom. The only required concept should be: being able to take the address of the mutex. (Because this makes it unique.) E.g. the requirement for these N2094 mutex concepts would make implementation of my proposed POD mutex variant impossible. E.g. the current boost mutex also does not need to make these explicit functions. Sorry if I misunderstood the document. I would be glad if someone (H. Hinnant?) could explain to me. Thank you. Roland

5 21

Boost regression notification (2006-11-01 [RC_1_34_0])
by Douglas Gregor 01 Nov '06

01 Nov '06

Boost Regression test failures Report time: 2006-11-01T10:24:34Z 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… 31 failures in 7 libraries iostreams (10) mpl (4) program_options (7) random (1) serialization (7) spirit (1) utility (1) |iostreams| bzip2_test: msvc-7.1 msvc-8.0 example_test: vc-6_5-stlport file_descriptor_test: cw-9.4 finite_state_filter_test: cw-9.4 gzip_test: msvc-7.1 msvc-8.0 mapped_file_test: cw-9.4 zlib_test: msvc-7.1 msvc-8.0 |mpl| multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: cw-9.4 variable_map_test_dll: cw-9.4 winmain_dll: cw-9.4 |random| random_test: intel-linux-9.0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |spirit| scanner_value_type_tests: gcc-4.1.0_linux |utility| operators_test: gcc-3.4.5_linux_x86_64

3 2

Re: [boost] Quicktime v210 format support (Re: GIL Review)
by Lubomir Bourdev 01 Nov '06

01 Nov '06

Lubomir Bourdev wrote: > 2. Now that we have writing out of the way, we can create a > model of an r-value channel reference (ChannelConcept, but > not MutableChannelConcept) that takes two channels and > returns a value half-way in between (or if generalization is > important, an arbitrary interpolation). Lets call it > InterpolatingChannel Of course, the moment I submitted the post I came up with a much simpler alternative. We don't need any InterpolatingChannel. We simply need to create a subbyte channel value. Synopsis: // Represents a channel *value* whose size is not byte-divisible // Models ChannelValueConcept template <typename UnpackedChannelValue, int NumBits> class packed_channel_value { public: typedef ChannelValue value_type; packed_channel_value(const value_type& data) : _data(data) {} packed_channel_value(const packed_channel_value& c) : _data(c._data) {} operator value_type() const { return _data&MAX_VALUE; } packed_channel_value& operator=(const value_type& data) { // warning: using this method may indicate a bug in your code! _data=data; return *this; } ... private: value_type _data; static const value_type MAX_VALUE = (1<<NumBits)-1; }; The difference between this and the packed_channel_reference class is that this one holds a copy of the data, whereas the packed channel reference holds a reference to the data which is located remotely. Now our channel type is simply: typedef packed_channel_value<uint16_t,10> v210_channel_t; Our pixel model is simply: typedef pixel<v210_channel_t, ycbcr_t> v210_pixel_t; We keep the same model of pixel iterator I outlined earlier. But we simply instantiate it with the correct values: reference v120_pixel_ptr::dereference() const { switch (index) { ... case 3: return reference( v120_channel_t(Y3), v120_channel_t((CB1+CB2)/2), v120_channel_t((CR1+CR2)/2)); } } Where "reference" is the same type as "value_type" (since this is an immutable view) Y3,CB1,CB2,CR1 and CR2 are the values of the corresponding 10-bit channels (some shift and mask math necessary) In short, dropping the requirement to write pixel-by-pixel into v210 (which is not a well defined operation anyway) results in a simpler and faster implementation. Lubomir

1 0

[xml] XML Reader Interface
by Sebastian Redl 01 Nov '06

01 Nov '06

Hi, Once again I'm turning to the list for discussion about a design issue in the XML library. This time I hope to avoid any discussion about the implementation on the library and focus on interface only. The interface in question is the reader interface, also known as pull interface. Like SAX, the pull interface is an event-based interface. There are a few event types (roughly, StartElement, EndElement, Characters, and a few more for other XML features), all of which provide come with some additional data: the element name, the character data, etc. There are two types of reader interfaces currently in use that I've found. I've come up with a third. I wonder which the people on this list would prefer, where they see their weaknesses and strengths. The names that I've given them are my own creation. 1) The Monolithic Interface Examples: .Net XMLReader, libxml2 XMLReader (modeled after the .Net one), Java Common API for XML Pull Parsing (XmlPull) (don't confuse with JSR 173 "StAX") In the monolithic interface, the XML parser acts as a cursor over the event stream. You call next() and it points to the next event in the stream. From there, you can query its type (usually some integral constants) and call some methods to retrieve the data. All methods are always available on the object; calling one that is not appropriate for the current event (e.g. getTagName() for a Characters event) returns a null value or signals an error. Pro: Event objects do not need to be allocated. The parser itself contains the entire state and can, for example, be passed down a recursive function group. Contra: You cannot store raw events: calling next() overwrites the current data. The parser contains a lot of state. This interface does not protect you in any way from calling inappropriate methods. 2) The Inheritance Interface Examples: JSR 173 "StAX" In the inheritance interface, the event types are modeled as a group of classes that all inherit from an Event base class. The parser acts as an iterator, Java style; calling next() returns a reference/pointer to the event object for this event. You use RTTI or a similar mechanism to find the type of the event, then cast the reference to the appropriate subclass. The subclasses then provide access to the data that is actually available for this event type. Pro: Cannot call methods that are inappropriate for the event. Event objects are independent of the parser and can be stored as they are. This is especially interesting if you have an event-based output system that uses the same event type: in this case, you can store the events, shuffle them, edit them, then pass them on to the writer. A proper analog to the stateful parser is harder to design. The parser contains less state, as it does not need to store the data that is currently queried. Contra: Event objects need to be allocated on the heap. In a non-GC language like C++, this is even more of a problem than in Java, as you have to use either a smart pointer or have the user responsible for deleting the object. The scenario of a group of functions as mentioned above is limited insofar as that if some functions want to process the same event, they need to be passed the current event along with the parser. 3) The Variant Interface Examples: None. I believe I came up with this entirely on my own. The variant interface seeks to combine the strengths of the other two interfaces. It uses a non-monolithic interface, that is, the parser acts like an iterator and the data is not stored within it. It does not return a reference to the event object, though, but instead a boost::variant of all possible events. This way, heap allocation of the event object is avoided, together with all the trouble coming with that. The event type can be determined either by calling variant::which, or with a variant visitor (type-safe!), or with a special get_base() function that works like get() but can retrieve a reference to a common base of all the variant types. (This is possible, although an implementation does not exist in Boost.) Pro: Cannot call methods that are inappropriate. The visitor system allows type-safe usage. (Of course, it also loses you part of the advantage of a pull interface over a push interface.) Does not need heap allocation if the event classes are properly designed (i.e. not trigger the case where the variant allocates heap memory.) Events can be stored, copied (another advantage over the inheritance interface, which would require a clone() method for that), and manipulated at will. They can be pre-allocated, a reference passed to next(), to save even the stack allocation. Contra: The issue about a group of function still applies. Independently of the type of interface chosen, another issue is important: the scope of the interface. Should it report all XML events, including those coming from DTD parsing? Should this be a user choice, or should there perhaps be two interfaces, one "high-level" and one "low-level"? Should errors be reported as error events, or as exceptions? Should this, too, be a user choice? How about warnings: exceptions are inappropriate for them. Should it be possible to disable them completely? All comments are welcome. Sebastian Redl

8 19

[Boost-bugs] [ boost-Bugs-1588713 ] log normal dist - error in _nsigma equation?
by SourceForge.net 01 Nov '06

01 Nov '06

Bugs item #1588713, was opened at 2006-11-01 09:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1588713&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: random Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Jens Maurer (jmaurer) Summary: log normal dist - error in _nsigma equation? Initial Comment: Is there an extra "/_mean" in the equation for _nsigma on line 104 of lognormal_distribution.hpp? i.e. shouldn't it be: _nsigma = sqrt(log(_sigma*_sigma/_mean+result_type (1))); instead of: _nsigma = sqrt(log (_sigma*_sigma/_mean/_mean+result_type(1))); ?? Thanks for the great lib, John Eddy (jpeddy(a)sandia.gov) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1588713&group_… ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost inspection notification (2006-11-01/RC_1_34_0) *X*
by Rene Rivera 01 Nov '06

01 Nov '06

Boost Inspection Report Run Date: 17:02:33 UTC, Wednesday 01 November 2006 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: 11675 files scanned 906 directories scanned (including root) 157 problems reported Problem counts: 0 files with invalid line endings 0 bookmarks with invalid characters 3 invalid urls 89 broken links 22 unlinked files 7 file/directory names issues 1 files with tabs 0 violations of the Boost min/max guidelines 35 usages of unnamed namespaces in headers (including .ipp files) Summary: archive (3) bind (1) boost-root (1) build (3) date_time (1) doc (2) filesystem (36) graph (3) iostreams (2) lambda (3) mpl (1) multi_array (2) parameter (2) ptr_container (1) regex (1) regression (13) serialization (1) signals (1) test (79) type_traits (1) Details: *R* invalid (cr only) line-ending *A* invalid bookmarks, invalid urls, broken links, unlinked files *N* file/directory names issues *T* tabs in file *M* uses of min or max that have not been protected from the min/max macros, or unallowed #undef-s *U* unnamed namespace in header |archive| boost/archive/basic_streambuf_locale_saver.hpp: *N* name exceeds 31 characters boost/archive/impl/xml_wiarchive_impl.ipp: *U* unnamed namespace at line 53 boost/archive/iterators/remove_whitespace.hpp: *U* unnamed namespace at line 57 |bind| boost/bind/placeholders.hpp: *U* unnamed namespace at line 25 |boost-root| index.htm: *A* broken link: ../doc/html/signals.html |build| tools/build/v1/variables.html: *A* unlinked file tools/build/v2/example/make/main.cpp.pro: *N* name contains more than one dot character ('.') tools/build/v2/test/test_system.html: *A* unlinked file |date_time| libs/date_time/xmldoc/date_time_docs_howto.html: *A* unlinked file |doc| doc/html/boost_math/inverse_complex.html: *A* unlinked file doc/html/jam.html: *A* unlinked file |filesystem| libs/filesystem/doc/do-list.htm: *A* invalid URL (hardwired file): file://?/ *A* invalid URL (hardwired file): file://?/UNC/ libs/filesystem/doc/i18n.html: *A* broken link: convenience.htm#basic_recursive_directory_iterator *A* broken link: exception.htm *A* broken link: operations.htm *A* broken link: operations.htm#Do-the-right-thing *A* broken link: operations.htm#is_directory *A* broken link: operations.htm#is_file *A* broken link: operations.htm#status libs/filesystem/doc/index.htm: *A* broken link: convenience.htm *A* broken link: fstream.htm *A* broken link: operations.htm#create_directory *A* broken link: operations.htm#create_hard_link *A* broken link: operations.htm#current_path *A* broken link: operations.htm#directory_iterator *A* broken link: operations.htm#equivalent *A* broken link: operations.htm#file_size *A* broken link: operations.htm#initial_path *A* broken link: operations.htm#is_file *A* broken link: operations.htm#is_symlink *A* broken link: operations.htm#status *A* broken link: operations.htm#symlink_status *A* broken link: path.htm#Canonical *A* broken link: path.htm#Grammar *A* broken link: path.htm#Normalized *A* broken link: path.htm#default_name_check *A* broken link: path.htm#name_check_mechanism *A* broken link: path.htm#normalize *A* broken link: path.htm#operator_eq *A* broken link: path.htm#synopsis libs/filesystem/doc/portability_guide.htm: *A* broken link: path.htm#name_check_typedef libs/filesystem/doc/tr2_proposal.html: *A* invalid URL (hardwired file): file:///C|/boost/site/libs/filesystem/doc/operations.htm#complete_note |graph| boost/graph/maximum_cardinality_matching.hpp: *N* name exceeds 31 characters libs/graph/doc/lengauer_tarjan_dominator_tree.htm: *N* name exceeds 31 characters libs/graph/doc/sorted_erdos_renyi_generator.html: *N* name exceeds 31 characters |iostreams| libs/iostreams/doc/acknowledgments.html: *A* unlinked file libs/iostreams/doc/concepts/multi-character.html: *A* unlinked file |lambda| boost/lambda/core.hpp: *U* unnamed namespace at line 62 boost/lambda/detail/lambda_functors.hpp: *U* unnamed namespace at line 25 boost/lambda/exceptions.hpp: *U* unnamed namespace at line 24 |mpl| boost/mpl/alias.hpp: *U* unnamed namespace at line 17 |multi_array| boost/multi_array/base.hpp: *U* unnamed namespace at line 69 libs/multi_array/test/generative_tests.hpp: *U* unnamed namespace at line 57 |parameter| libs/parameter/doc/html/python.html: *A* broken link: tag::x(int *A* broken link: tag::y*(int |ptr_container| libs/ptr_container/doc/tutorial_example.html: *A* unlinked file |regex| libs/regex/performance/input.html: *A* unlinked file |regression| regression/.htaccess: *N* leading character of ".htaccess" is not alphabetic tools/regression/xsl_reports/xsl/html/issues_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/library_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/library_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/make_tinyurl.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/summary_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/html/summary_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/issues_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/library_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/library_user_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/make_tinyurl.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_developer_legend.html: *A* unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_user_legend.html: *A* unlinked file |serialization| libs/serialization/src/basic_xml_grammar.ipp: *U* unnamed namespace at line 43 |signals| boost/signals/detail/named_slot_map.hpp: *T* |test| boost/test/floating_point_comparison.hpp: *U* unnamed namespace at line 206 *U* unnamed namespace at line 228 boost/test/impl/cpp_main.ipp: *U* unnamed namespace at line 42 boost/test/impl/exception_safety.ipp: *U* unnamed namespace at line 400 boost/test/impl/framework.ipp: *U* unnamed namespace at line 199 boost/test/impl/plain_report_formatter.ipp: *U* unnamed namespace at line 45 boost/test/impl/progress_monitor.ipp: *U* unnamed namespace at line 38 boost/test/impl/results_collector.ipp: *U* unnamed namespace at line 106 boost/test/impl/results_reporter.ipp: *U* unnamed namespace at line 48 boost/test/impl/unit_test_log.ipp: *U* unnamed namespace at line 79 boost/test/impl/unit_test_monitor.ipp: *U* unnamed namespace at line 35 boost/test/impl/unit_test_parameters.ipp: *U* unnamed namespace at line 50 boost/test/results_collector.hpp: *U* unnamed namespace at line 40 boost/test/test_tools.hpp: *U* unnamed namespace at line 255 boost/test/utils/iterator/token_iterator.hpp: *U* unnamed namespace at line 166 boost/test/utils/named_params.hpp: *U* unnamed namespace at line 216 boost/test/utils/runtime/cla/dual_name_parameter.ipp: *U* unnamed namespace at line 43 boost/test/utils/runtime/cla/modifier.hpp: *U* unnamed namespace at line 34 boost/test/utils/runtime/env/modifier.hpp: *U* unnamed namespace at line 34 boost/test/utils/runtime/file/config_file.hpp: *U* unnamed namespace at line 169 *U* unnamed namespace at line 64 *U* unnamed namespace at line 74 boost/test/utils/runtime/file/config_file_iterator.hpp: *U* unnamed namespace at line 68 boost/test/utils/trivial_singleton.hpp: *U* unnamed namespace at line 52 *U* unnamed namespace at line 61 libs/test/build/msvc71_proj/config_file_iterator_test.vcproj: *N* name exceeds 31 characters libs/test/doc/components/prg_exec_monitor/index.html: *A* broken link: ../../../../../boost/test/cpp_main.hpp libs/test/doc/components/test_tools/index.html: *A* broken link: ../../tests/boost_check_equal_str.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_CLOSE.html: *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_MESSAGE.html: *A* broken link: BOOST_MESSAGE.html libs/test/doc/components/test_tools/reference/BOOST_CHECK_SMALL.html: *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/test_tools/reference/tools_list.html: *A* broken link: ../../btl1.gif *A* broken link: BOOST_CHECK_CLOSE_FRACTION.html libs/test/doc/components/utf/components/index.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/components/test_case/abstract_interface.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/auto_register_facility.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/boost_function_tc.html: *A* broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/class_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/function_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_boost_function_tc.html: *A* broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_class_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/param_function_tc.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_case/tc_template.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_log/custom_log_formatter.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_log/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_result/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/components/test_suite/index.html: *A* broken link: ../../../btl1.gif libs/test/doc/components/utf/index.html: *A* broken link: getting_started/index.html libs/test/doc/components/utf/parameters/build_info.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/catch_system_errors.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/detect_memory_leaks.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/index.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/log_format.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/log_level.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/no_result_code.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/output_format.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/random.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/report_format.html: *A* broken link: ../../../../../LICENSE_1_0.txt *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/report_level.html: *A* broken link: ../../btl1.gif libs/test/doc/components/utf/parameters/show_progress.html: *A* broken link: ../../btl1.gif libs/test/doc/examples/unit_test_example1.html: *A* broken link: ../../example/unit_test_example1.cpp libs/test/doc/examples/unit_test_example2.html: *A* broken link: ../../example/unit_test_example2.cpp libs/test/doc/examples/unit_test_example3.html: *A* broken link: ../../example/unit_test_example3.cpp libs/test/doc/examples/unit_test_example4.html: *A* broken link: ../../example/unit_test_example4.cpp libs/test/doc/examples/unit_test_example5.html: *A* broken link: ../../example/unit_test_example5.cpp *A* broken link: ../../example/unit_test_example5.input libs/test/doc/tests/auto_unit_test_test.html: *A* broken link: ../../test/auto_unit_test_test.cpp libs/test/doc/tests/auto_unit_test_test_mult.html: *A* broken link: ../../test/auto_unit_test_test_mult1.cpp *A* broken link: ../../test/auto_unit_test_test_mult2.cpp libs/test/doc/tests/unit_test_suite_ex_test.html: *A* broken link: ../../test/unit_test_suite_ex_test.cpp libs/test/doc/tutorials/hello_the_testing_world.html: *A* broken link: ../../../../../LICENSE_1_0.txt *A* broken link: ../execution_monitor/index.html libs/test/doc/tutorials/new_year_resolution.html: *A* broken link: ../../../../../../LICENSE_1_0.txt |type_traits| libs/type_traits/cxx_type_traits.htm: *A* unlinked file

1 0