- Boost - lists.boost.org

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

29 Mar '07

Boost Inspection Report Run Date: 16:05:58 UTC, Thursday 29 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: 11449 files scanned 908 directories scanned (including root) 199 problems reported Problem counts: 1 files with invalid line endings 0 bookmarks with invalid characters 3 invalid urls 107 broken links 21 unlinked files 22 file/directory names issues 1 files with tabs 9 violations of the Boost min/max guidelines 35 usages of unnamed namespaces in headers (including .ipp files) Summary: archive (3) bind (1) boost-root (3) build (2) date_time (1) doc (2) filesystem (37) graph (2) iostreams (3) lambda (3) math (8) more (1) mpl (4) multi_array (2) ptr_container (1) python (10) regex (1) regression (32) serialization (1) test (81) 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/hmtl/date_time.html *A* broken link: doc/hmtl/date_time/details.html#changes *A* broken link: more/BoostCon07.html |build| tools/build/v2/test/test_system.html: *A* unlinked file tools/build/v2/tools/python.jam: *R* |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: ../build/Jamfile *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| libs/graph/example/file_dependencies.cpp: *M* violation of Boost min/max guidelines on line 139 libs/graph/test/serialize.cpp: *T* |iostreams| libs/iostreams/doc/acknowledgments.html: *A* unlinked file libs/iostreams/doc/concepts/multi-character.html: *A* unlinked file libs/iostreams/doc/installation.html: *A* broken link: ../../../tools/build/v1/build_system.htm |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 |math| libs/math/test/common_factor_test.cpp: *M* violation of Boost min/max guidelines on line 146 *M* violation of Boost min/max guidelines on line 147 *M* violation of Boost min/max guidelines on line 193 *M* violation of Boost min/max guidelines on line 194 |more| more/separate_compilation.html: *A* broken link: ../libs/config/test/link/test/Jamfile.v2 |mpl| boost/mpl/alias.hpp: *U* unnamed namespace at line 17 libs/mpl/doc/refmanual/for-each.html: *A* broken link: ./value-initialized.html |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 |ptr_container| libs/ptr_container/doc/tutorial_example.html: *A* unlinked file |python| libs/python/doc/building.html: *A* broken link: ../../../tools/build/v1/build_system.htm *A* broken link: ../../../tools/build/v1/build_system.htm#user_globals *A* broken link: ../../../tools/build/v1/build_system.htm#variants libs/python/doc/tutorial/doc/html/python/hello.html: *A* broken link: ../../../../../example/tutorial/Jamrules libs/python/doc/tutorial/index.html: *A* broken link: ../../../LICENSE_1_0.txt libs/python/doc/v2/May2002.html: *A* broken link: ../../../../tools/build/v1/build_system.htm *A* broken link: ../../../../tools/build/v1/gen_aix_import_file.py libs/python/doc/v2/faq.html: *A* broken link: ../../../../tools/build/v1/build_system.htm |regex| libs/regex/performance/input.html: *A* unlinked file |regression| regression/.htaccess: *N* leading character of ".htaccess" is not alphabetic tools/regression/test/test-cases/incremental/bjam.log.1: *N* name contains more than one dot character ('.') tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/compile-fail.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/completed.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/compile-fail.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/completed.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/lib.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/misfire.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/no-run.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/run_pyd.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/expected/test-case.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/test-case.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_is_test_log_complete/test-driver.xsl: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_re_match/expected/test_re_match.xml: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ tools/regression/xsl_reports/test/test-components/test_test_case_status/explicit-failures-markup.xml.test: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ *N* name contains more than one dot character ('.') *N* name exceeds 31 characters tools/regression/xsl_reports/test/test-components/test_test_structure/explicit-failures-markup.xml.test: *N* file path will exceed 100 characters in a directory tree with a root of the form boost_X_XX_X/ *N* name contains more than one dot character ('.') *N* name exceeds 31 characters 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 |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 262 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/compilation.html: *A* broken link: ../../../build/Jamfile 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/compilation.html: *A* broken link: ../../../build/Jamfile 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

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

29 Mar '07

Boost Regression test failures Report time: 2007-03-29T01:01:27Z 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… 26 failures in 3 libraries date_time (1) parameter (4) python (21) |date_time| testmicrosec_time_clock: borland-5.8.2 |parameter| python_test: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux gcc-cygwin-3.4.4 |python| bases: gcc-4.1.1_sunos_i86pc exec: gcc-4.1.1_sunos_i86pc exec-dynamic: gcc-4.1.1_sunos_i86pc extract: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux list: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux pickle1: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux pickle2: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux pickle3: gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux pointee: gcc-4.1.1_sunos_i86pc pointer_type_id_test: gcc-4.1.1_sunos_i86pc upcast: gcc-4.1.1_sunos_i86pc

1 0

More filesystem::directory_iterator woes (AIX endless loop)
by Michael Klein 29 Mar '07

29 Mar '07

Hi, iterating over a directory on AIX results in an endless loop because of funny return codes from readdir_r(): http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.… Specifically, readdir_r() sets errno to EBADF upon end-of-directory. Currently, dir_itr_increment() detects an error condition and returns, but without ever calling dir_itr_close(), and the DIR handle never gets closed. Workaround: --- ../boost/libs/filesystem/src/operations.cpp.orig +++ ../boost/libs/filesystem/src/operations.cpp @@ -1250,10 +1250,9 @@ BOOST_ASSERT( buffer != 0 ); dirent * entry( static_cast<dirent *>(buffer) ); dirent * result; - int return_code; - if ( (return_code = readdir_r_simulator( static_cast<DIR*>(handle), - entry, &result )) != 0 ) return error_code( errno, errno_ecat ); + int return_code( readdir_r_simulator( static_cast<DIR*>(handle), entry, &result ) ); if ( result == 0 ) return dir_itr_close( handle, buffer ); + if ( return_code != 0 ) return error_code( errno, errno_ecat ); target = entry->d_name; # ifdef BOOST_FILESYSTEM_STATUS_CACHE if ( entry->d_type == DT_UNKNOWN ) // filesystem does not supply d_type value Kind regards, -- Michael #exclude <windows.h>

1 0

[XML] Searching for an XML parsing library in boost
by Shibu Bera 29 Mar '07

29 Mar '07

> I would like to know, > if any library for parsing XML file is available in boost or not. > I srearched in the boost.org site for the same but, >I cound't get any library as such. >If library is present, please let me know the details. >If not, please allow me to know, if any work is going in the concern topic. Thank you, -- Regards, Shibu

12 46

boost::filesystem::directory_iterator not working on NFS mounts
by Michael Klein 29 Mar '07

29 Mar '07

Hello list, the directory_iterator (current CVS) doesn't work if the iterated directory resides on an NFS mount and fails with an exception in boost::filesystem::basic_directory_iterator's constructor. The NFS server here runs Linux, and the iterator fails at least on clients running Solaris (Invalid argument) or HP-UX (Operation not supported). This reason is because of the call to pathconf(_PC_NAME_MAX) in directory_iterator::dir_itr_first() which fails for directories residing on NFS mounts, probably because the client doesn't know about the server's limits. Although arbitrary assumptions are usally not the best idea I think it's reasonable to use PATH_MAX as maximum length in this case. Not being able to use a directory_iterator on a NFS mount is a rather severe limitation, IMHO. As a workaround I'm using this patch right now: --- boost.orig/boost/libs/filesystem/src/operations.cpp +++ boots/boost/libs/filesystem/src/operations.cpp @@ -1187,7 +1187,21 @@ return error_code( errno, errno_ecat ); target = dummy_first_name; long pc_name_max( ::pathconf( dir.c_str(), _PC_NAME_MAX ) ); - if ( pc_name_max == -1L ) return error_code( errno, errno_ecat ); + if ( pc_name_max == -1L ) + { + switch ( errno ) + { + case EINVAL: +#ifdef EOPNOTSUPP + case EOPNOTSUPP: // HP-UX returns this +#endif + pc_name_max = PATH_MAX; + break; + + default: + return error_code( errno, errno_ecat ); + } + } dirent de; buffer = std::malloc( (sizeof(dirent) - sizeof(de.d_name)) + static_cast<std::size_t>( pc_name_max ) + 1 ); Any opinions? Kind regards, -- Michael #exclude <windows.h>

1 0

boost::iostream: Who's in charge ?
by Philippe Vaucher 29 Mar '07

29 Mar '07

Hello, Who's in charge of boost::iostream ? >From what I found on the mailing list, the lib author did quit boost development. The problem is, the doc isn't even complete, as http://boost.org/libs/iostreams/doc/guide/buffering.html shows. So right now it looks like nobody knows the lib entirely, like no one seems to know how to turn buffering off, despite me asking there and on irc. Actually I'm not even sure my problem is related to buffering, but no one can confirm / refute my guessing. I think this is somewhat dangerous to let a lib in a kind of "abandoned" state. My 0.02$. Philippe

1 0

Re: [boost] Boost.Threads, N2178, N2184, et al
by Emil Dotchevski 28 Mar '07

28 Mar '07

> Connection between pthreads and C++ threads: The critical connection > is cancellation. If you phthread_cancel a C++ thread, what happens? > If you thread::cancel() a pthreads thread, what happens? In the ideal > world everything would just work. I'm not convinced this is > practical. We can say "oh well, whatever" and not standardize what happens when thread cancellation crosses the C/C++ language barrier; however this approach doesn't work where the rubber meets the road: at some point, someone will have to define these semantics. Without a standard, the implementation-defined semantics (as of today) vary from platform to platform; I do not see how this is helpful. > Benefit of non-copyable (but movable) thread handle: It is all in how > you view: join, detach and cancel. If these are considered non-const > operations on the thread, then the sole-ownership model is much > simpler. I've got a thread, I own it, nobody else does, I can do non- > const things with it without fear of disturbing the universe. If > join, detach and cancel are const operations, (and if all other things > you can do through the handle are const) then under-the-cover > reference semantics are benign. On Windows, you can have two joins on the same thread. Copyable thread handles can support this behavior directly. How does one achieve the same thing with N2184::thread semantics? > This is quite analogous to reference counted strings: A reference > counted mutable string is complicated. If you modify one, you either > have to copy it so others sharing the data don't see the modification, > or you accept the fact that your string has reference semantics: > modify it here, and all other copies see what you've done. And OS > threads aren't copyable, so reference semantics for the handle are the > only option.> > A reference counted immutable string is quite simple. You never > modify it. The fact that it is shared is virtually undetectable (an > implementation detail). Not only strings, sharing mutable objects of any type is complicated. Sometimes we define const interfaces which turn sharing into an implementation detail, and sometimes we deal with the complexities of mutable operations. > Current thread handle: This feeds from the sole ownership view vs the > shared ownership view. Yes, this is why I mentioned it. You can't have non-copyable semantics and allow the current thread to be able to take a self handle. > In the sole-ownership view (value semantics), > there is only one owner of a thread. Only the owner can do non-const > things with it. Even the thread does not own itself unless it has > been passed its own sole-ownership handle. This simplifies (imho) > reasoning about non-const operations on the thread. It simplifies the implementation and/or the documentation, and yes, simpler is better -- but only if the functionality that's taken away is not needed in practice. I don't think the boost::thread documentation claim that "it isn't needed very often" is acceptable. If even one valid use case exists that requires shared handles, then we either need shared handles or we need to show that the use case is in fact invalid. > Otoh, if there is > a shared-ownership model (reference semantics), then one has copyable > thread handles and getting a copy of your own handle is very sensible. I see things the other way around: if there are valid reasons for getting a copy of your own handle, then a shared-ownership model is sensible. > thread::id is a practical exception to this model. It is common to be > able to identify threads, especially to see if the last thread that > executed *here* is *me* (recursive mutex prime example). So > thread::id is copyable, and you can get a copy of your own > thread::id. One can only do const-things with a thread::id, making it > harmless to share (can't tell the difference between reference > semantics and value semantics). If I have shared thread handles, I can associate arbitrary data with a thread by a map<handle,data>. Independently, somebody else may have their own map<handle,data>. If I use thread::id in a similar way, how do I know when to dispose of the associated data? (if I remember correctly, if I have a thread::id, I can't check whether the corresponding thread has ended.) > In general: thread manipulation of yourself is neither specifically > allowed nor disallowed in N2184. There's a single owner to every > thread. If you want to manipulate that thread, you have to be the > owner, even if that thread is yourself. No special case. Although > joining with yourself could be considered hazardous to your health and > frowned upon by your universe as a whole. :-) Understood. Emil Dotchevski _________________________________________________________________ i'm making a difference. Make every IM count for the cause of your choice. Join Now. http://clk.atdmt.com/MSN/go/msnnkwme0080000001msn/direct/01/?href=http://im…

11 85

Re: [boost] [ublas] [units] interfacing with boost::ublas
by Matthias Schabel 28 Mar '07

28 Mar '07

> The implementation of type deduction of uBLAS is really > complicated, so > we are still looking for a simpler version. The use of result_type of > operator+ was already a big advantage. However the current > implementation assumes that all operation (+,-,*,/) follow the same > rules. A modification of this assumption would mean a big redesign of > many classes. Any help is welcome. Why is type deduction complicated? Is there some reason to not obey the rules followed by the compiler itself? You might want to look at the header operators.hpp in the proposed Boost.Units library in the Vault (mcs_units_v0.7.2.zip) - this file contains all the type deduction needed for this library, and the type operations needed for compile-time dimensional analysis have to be much more complex than those in ublas. Even if you don't have typeof support, it is possible to simply define the following helper classes specialized for the supported built-in types (if a bit tedious) : template<typename X> struct unary_plus_typeof_helper; template<typename X> struct unary_minus_typeof_helper; template<typename X,typename Y> struct add_typeof_helper; template<typename X,typename Y> struct subtract_typeof_helper; template<typename X,typename Y> struct multiply_typeof_helper; template<typename X,typename Y> struct divide_typeof_helper; template<typename X,typename Y> struct power_typeof_helper; template<typename X,typename Y> struct root_typeof_helper; so template<> struct add_typeof_helper<int,double> { typedef double type; } etc... Then all operators return the appropriate type : template<class X,class Y> typename add_typeof_helper<X,Y>::type operator+(const ublas<X>&,const ublas<Y>&); Deduction in expression templates should just happen correctly if they are implemented correctly, since you should just get : (x+y)*z -> multiply_typeof_helper< add_typeof_helper<X,Y>::type,Z>::type I have implemented this in my own array library with relatively little difficulty. Matthias

1 0

[optional] New implementation of boost/none.hpp hits Borland 5.6.4 bug
by Nicola Musatti 28 Mar '07

28 Mar '07

Hallo, unfortunately the recently committed changes to Boost.Optional uncover a bug in BCB6, i.e. borland 5.6.4 . As 1.34 is going to be the last Boost release to officially support this compiler, it would be very important to fix this problem before the release. I see that currently no tester is running tests for borland 5.6.4; if none is available I could run the tests locally on my machine and report back or, with a little hand-holding, run a full regression run. The bug can be observed by compiling the following very simple source file: #include <boost/optional.hpp> #include <sstream> This result in a rather incomprehensible error message: [C++ Error] _ctype.h(124): E2034 Cannot convert 'int *' to 'const ctype_base::mask *' The problem appears to be triggered by the relational operator overloads that take a none_t as a first argument (don't ask me why!). By commenting out lines 838-866 in boost/optional/optional.hpp the problem disappears. The only workaround I was able to find is to revert to the previous implementation of boost/none.hpp, as in the following: #include <boost/detail/workaround.hpp> namespace boost { #if ! BOOST_WORKAROUND(__BORLANDC__, <= 0x564) namespace detail { struct none_helper{}; } typedef int detail::none_helper::*none_t ; none_t const none = ((none_t)0) ; #else enum none_t {none = 0}; #endif } // namespace boost Given this is such a simple header it may be reasonable not to include boost/detail/workaround.hpp here and explicitly state the condition. Note that this problem is not present in borland 5.8.2. Cheers, Nicola Musatti

2 6

Re: [boost] [Review] Quantitative Units library review begins today March 26
by Steven Watanabe 28 Mar '07

28 Mar '07

AMDG "Eric Lemings" wrote: > <snip> > > Undoubtedly, the scope of this library should include the dimensional > analysis framework which defines the fundamental types/metatypes (e.g. > dimension, unit, quantity), their semantics, and their operations. It > should also include only the most common dimensions such as the physical > dimensions (time, length, mass, etc.) and allow, at least, other > universal > dimensions (e.g. currency). Other, more specialized dimensions should > be defined elsewhere. > That was one of out goals. The units that we have are implemented solely in terms of the dimension/unit/quantity framework. > The scope should not include any facilities for input and output. It > should also not prevent such support however. (Input and output of > units and measures can be handled by extending C++ locales with new > facets. C++ locales already deal with I/O of time and money. More > about internalization and localization below.) > Input is definitely beyond the scope of the library. We have implemented primitive output.... On further thought, we should probably just have an output operator for quantity that prints the value_type then the unit and leave unit output alone. > The scope should not classify units of measurement into exclusionary > systems. True, many programs/programmers will have restrictions that > prevent/exclude use of any units of measurement outside a well-known > set of units but the other extreme is also quite possible. A program > may allow arithmetic/conversions between any and all units known to the > development/operating environment. In such cases, the programmer is not > concerned in the least with systems of units and classification of > units into systems becomes totally irrelevant (and impossible for many > older and rarer units of measure). Therefore, if constraining units > into discrete systems is a desired objective, it should be the > responsibility of the program rather than the library. > Allowing conversion between units having different dimensions and allowing fundamental units whose dimensions are not fundamental e.g. quarts for volume is very very difficult to implement. Off hand, I think that it requires defining some special system (probably SI) and converting through that system. > Whether the scope should include a particuar system of units (e.g. SI > units, Imperial units) is debatable. Personally, I believe each system > of units should be treated much the same way C++ currently treats > locales. The library may contain, even mandate, a "default" set of > units (e.g. SI) but including even the most common modern units is > beyond the scope of the library. (Which units are modern? Which units > are common?) Each system of units can therefore be defined separately > as an extension to the underlying framework. > Absolutely > I'll post more specific review comments about the proposal later. > > Thanks, > Eric. > Thanks! In Christ, Steven Watanabe

7 16