- Boost - lists.boost.org

Re: [boost] [filesystem] revised function to determineavailablefile system space
by Greer, Joe 16 Sep '05

16 Sep '05

> In looking at this a bit further, both POSIX and windows distinguish > between > total free space and free space available "to nonprivileged process" > (POSIX) > or "to caller" (Windows). > > To accommodate this, we might have: > > boost::uintmax_t capacity(path const &); > boost::uintmax_t total_free_space(path const &); > boost::uintmax_t available_free_space(path const &); > IMO, total_free_space() and available_free_space() should be tied together so that you can make some relationship between them. If they are implemented as separate calls, then you don't really know what disk activity went on between the first and second calls. I can see a case where the total_free_space might be < than the available_free_space if you called the functions in the wrong order and there was disk activity going on. joe

2 1

Re: [boost] Checked Integral Class
by Matt Doyle 16 Sep '05

16 Sep '05

> From: "michael toksvig" <michaeltoksvig(a)yahoo.com> > > > "Rob Stewart" <stewart(a)sig.com> wrote in message > > > > news:200509161700.j8GH0nHo017101@shannonhoon.balstatdev.susq.com... > > > It's surprising for the result type to have a less restrictive > > > range than the inputs. > > > > add two numbers in the 1-10 range, and you invariably end > up with a number > > in the 2-20 range > > Yep. However, when considering constrained ranges, I find it > surprising that the result would be *permitted* to exceed the > constraints of the inputs. > > IOW, I'd have expect the result to be constrained to be 2-10. > Yes, that means that combinations exist that violate that > constraint, but at least it wouldn't surprise me. > <snip> YES, that's exactly the point I was trying to make earlier - you just did a much better job of explaining it :) IMO, the constraints and/or policies set forth when the type was defined must apply for the lifetime of the type. Matt Scanned by Fortigate {X3BTB534}

2 1

Re: [boost] Checked Integral Class
by Matt Doyle 16 Sep '05

16 Sep '05

> > Maciej Sobczak wrote: > > > > In my opinion both approaches have their uses, just like > std::vector and > > boost::array. > > > > Right. We could support both ways by making the type of range > the value > is checked against configurable. I think of a static_range<> for > compile-time checked values and dynamic_ranges to be setup at runtime. Question though. Which is going to be more useable; having separate methods for static and runtime, or having one that checks the range at compile time and then continues to maintain that original policy for the lifetime of the type? Actually, that might be something that be selectable in the policy class, if it's possible, something like apply_contraints_at [COMPILE_TIME, RUN_TIME, BOTH] Any thoughts? Matt Scanned by Fortigate {X3BTB534}

1 0

Vault: Missing Content? Search?
by Caleb Epstein 16 Sep '05

16 Sep '05

I know content disappaeared from the "Vault" at http://boost-consulting.com/vault/ not long ago, but I thought it had been restored. I am looking for the "factory3.zip "file that used to be there, but I'm unable to find it. In fact most of the directories are currently empty. Also, is there any way to make this interface searchable? While the current neat directory structure is nice, it sure makes it difficult to find an arbitrary file that might be there (e.g. does factory belong in "Containers", "Generic Programming", "Miscellaneous" or someplace else?). A search box would help a lot as the content is expanded over time. -- Caleb Epstein caleb dot epstein at gmail dot com

3 2

Boost regression notification (2005-09-16 [HEAD])
by Douglas Gregor 16 Sep '05

16 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-16T05:00:20Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 259 failures in 17 libraries: algorithm/string (1) concept_check (14) date_time (5) filesystem (8) foreach (7) graph (4) iostreams (1) math (6) mpl (2) parameter (17) python (1) regex (36) serialization (40) spirit (2) thread (24) typeof (87) wave (4) |algorithm/string| regex: gcc-3_3-darwin |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-7_1 vc-7_1 |date_time| testlocal_time_iterator: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc testlocal_time_period: gcc-2.95.3-linux msvc |filesystem| convenience_test: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: msvc |foreach| user_defined: cw-8_3 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |iostreams| regex_filter_test: gcc-3_3-darwin |math| octonion_test: gcc-4_0-darwin gcc-4_0-darwin quaternion_test: gcc-4_0-darwin gcc-4_0-darwin special_functions_test: gcc-4_0-darwin gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin gcc-4_0-darwin |parameter| basics: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc macros: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc unnamed: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |python| data_members: msvc |regex| bad_expression_test: gcc-3_3-darwin captures_example: gcc-3_3-darwin captures_test: gcc-3_3-darwin collate_info: gcc-3_3-darwin concept_check: gcc-3_3-darwin credit_card_example: gcc-3_3-darwin grep: gcc-3_3-darwin icu_example: gcc-3_3-darwin mfc_example: gcc-3_3-darwin object_cache_test: gcc-3_3-darwin partial_regex_grep: gcc-3_3-darwin partial_regex_match: gcc-3_3-darwin posix_api_check: gcc-3_3-darwin posix_api_check_cpp: gcc-3_3-darwin recursion_test: gcc-3_3-darwin regex_config_info: gcc-3_3-darwin regex_dll_config_info: gcc-3_3-darwin regex_grep_example_1: gcc-3_3-darwin regex_grep_example_2: gcc-3_3-darwin regex_grep_example_3: gcc-3_3-darwin regex_grep_example_4: gcc-3_3-darwin regex_iterator_example: gcc-3_3-darwin regex_match_example: gcc-3_3-darwin regex_merge_example: gcc-3_3-darwin regex_regress: gcc-3_3-darwin regex_regress_dll: gcc-3_3-darwin regex_replace_example: gcc-3_3-darwin regex_search_example: gcc-3_3-darwin regex_split_example_1: gcc-3_3-darwin regex_split_example_2: gcc-3_3-darwin regex_timer: gcc-3_3-darwin regex_token_iterator_eg_1: gcc-3_3-darwin regex_token_iterator_eg_2: gcc-3_3-darwin static_mutex_test: gcc-3_3-darwin msvc wide_posix_api_check_cpp: gcc-3_3-darwin |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_barrier: msvc test_barrier_lib: intel-9.0-linux msvc test_condition: msvc test_condition_lib: intel-9.0-linux msvc test_mutex: msvc test_mutex_lib: intel-9.0-linux msvc test_once: msvc test_once_lib: intel-9.0-linux msvc test_read_write_mutex: msvc test_read_write_mutex_lib: intel-9.0-linux msvc test_thread: msvc test_thread_lib: intel-9.0-linux msvc test_tss: msvc test_tss_lib: intel-9.0-linux msvc test_xtime: msvc test_xtime_lib: intel-9.0-linux msvc |typeof| data_member_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux data_member_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 function_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_ptr_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 function_ref_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_ref_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 lvalue_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lvalue_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc member_function_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_function_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux modifiers_native: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_int_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_tpl_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_tpl_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc template_type_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_type_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 type_emulation: borland-5_6_4 cw-8_3 cw-9_4 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux type_native: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

1 0

stl_concept_covering.cpp terminally broken in 1.33.x ?
by John Maddock 16 Sep '05

16 Sep '05

Looking at the regressions for 1.33.1 stl_concept_covering.cpp seems not to compile with any compiler at present. Looking at the source there is one obvious error: out = std::fill_n(out, n, value); But fill_n returns void ! Then there are lots of preprocessor sections along the lines of: #if defined(__GNUC__) typedef less_than_op_first_archetype<> FT; typedef less_than_op_second_archetype<> T; #elif defined(__KCC) // The KAI version of this uses a one-argument less-than function // object. typedef less_than_comparable_archetype<> T; typedef convertible_to_archetype<T> FT; #endif forward_iterator_archetype<FT> fi; T value(dummy_cons); fi = std::lower_bound(fi, fi, value); Which can clearly never compiler on any compiler other than GCC or KCC. However, fixing these issues still doesn't get the code compiling on any platform I have access to. Some of these will be std lib conceptual errors, but *something* should compile this source, otherwise what's the point? Regards, John.

1 0

Fwd: Boost thread library bugs
by Sean Parent 16 Sep '05

16 Sep '05

Begin forwarded message: > From: "Mike Schuster" <schuster(a)adobe.com> > Date: September 15, 2005 6:11:03 PM PDT > To: "Sean Parent" <sparent(a)adobe.com> > Subject: RE: Boost thread library bugs > > > I just downloaded it and took a look. > > Bugs 1) and 2) still exist. > > Bug 3): read_write_mutex had a major rewrite, and looking at the new > code, bug 3) appears to have been discovered and addressed. > However, the > code is quite a bit more complicated (1700 lines versus 1100 lines). I > will do some testing and more investigation in the next few days. > > (By the way, my implementation of a "most useful subset" (in my > opinion) > of read_write_mutex is 100 lines. Boost may have gone overboard > here at > the price of performance.) > > -Mike > > -----Original Message----- > From: Sean Parent [mailto:sparent@adobe.com] > Sent: Thursday, September 15, 2005 3:46 PM > To: Mike Schuster > Subject: Re: Boost thread library bugs > > Have you looked at 1.33.0 yet to see if any of these are fixed? > Sean >

3 2

[regex][1.33.1] Build with MinGW+STLport-5 fails.
by Rene Rivera 16 Sep '05

16 Sep '05

Ran into a problem while verifying building. With the combination of MinGW 3.4.2 - Runtime 3.8 - STLport-5 the *release* variant of Boost.Regex fails to build with this error: In file included from C:/DevRoots/Boost/boost_1_33/boost/regex/v4/regex.hpp:97, from C:/DevRoots/Boost/boost_1_33/boost/regex.hpp:31, from C:\DevRoots\Boost\boost_1_33\libs\regex\build\../src/instances.cpp:30: C:/DevRoots/Boost/boost_1_33/boost/regex/v4/instances.hpp:188: error: duplicate explicit instantiation of `void boost::match_results<BidiIterator, Allocator>::maybe_assign(const boost::match_results<BidiIterator, Allocator>&) [with BidiIterator = const char*, Allocator = stlp_std::allocator<boost::sub_match<const char*> >]' C:/DevRoots/Boost/boost_1_33/boost/regex/v4/instances.hpp:195: error: duplicate explicit instantiation of `void boost::re_detail::perl_matcher<BidiIterator, Allocator, traits>::construct_init(BidiIterator, BidiIterator, boost::match_results<BidiIterator, Allocator>&, const boost::basic_regex<typename traits::char_type, traits>&, boost::regex_constants::match_flag_type) [with BidiIterator = const char*, Allocator = stlp_std::allocator<boost::sub_match<const char*> >, traits = boost::regex_traits<char, boost::cpp_regex_traits<char> >]' C:/DevRoots/Boost/boost_1_33/boost/regex/v4/instances.hpp:196: error: duplicate explicit instantiation of `bool boost::re_detail::perl_matcher<BidiIterator, Allocator, traits>::match() [with BidiIterator = const char*, Allocator = stlp_std::allocator<boost::sub_match<const char*> >, traits = boost::regex_traits<char, boost::cpp_regex_traits<char> >]' C:/DevRoots/Boost/boost_1_33/boost/regex/v4/instances.hpp:197: error: duplicate explicit instantiation of `bool boost::re_detail::perl_matcher<BidiIterator, Allocator, traits>::find() [with BidiIterator = const char*, Allocator = stlp_std::allocator<boost::sub_match<const char*> >, traits = boost::regex_traits<char, boost::cpp_regex_traits<char> >]' It looks like the code is supposed to be guarded for GCC but it might be conflicting since it's STLport also. Any ideas? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 2

[Boost-bugs] [ boost-Bugs-1292635 ] uBLAS::subslice doesn't work
by SourceForge.net 16 Sep '05

16 Sep '05

Bugs item #1292635, was opened at 2005-09-16 00:27 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=1292635&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: uBLAS::subslice doesn't work Initial Comment: Hello all, I had a problem with compiling a following code for testing subslice() on uBLAS: -- test.cpp #include <boost/numeric/ublas/vector.hpp> #include <boost/numeric/ublas/vector_proxy.hpp> #include <boost/numeric/ublas/io.hpp> int main () { using namespace boost::numeric::ublas; vector<double> v (3); for (int i = 0; i < 3; ++ i) boost::numeric::ublas::subslice (v, 0, 1, 3) (i) = i; std::cout << v << std::endl; } -- end of test.cpp % g++ test.cpp test.cpp: In function `int main()': test.cpp:9: error: no matching function for call to `subslice(boost::numeric::ub las::vector<double, boost::numeric::ublas:: unbounded_array<double, std::allocato r<double> > >&, int, int, int)' I guess this is due to some typos on vector_proxy.hpp. I hope attached patch (from Revision 1.45) helps. Regards, Shun Sakuraba sakuraba {at} cb.k.u-tokyo.ac.jp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1292635&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Fwd: Boost thread library bugs
by Sean Parent 16 Sep '05

16 Sep '05

I don't regularly read the boost mailing list - so please reply directly to me or Mike. Sean Begin forwarded message: > From: "Mike Schuster" <schuster(a)adobe.com> > Date: September 15, 2005 3:42:26 PM PDT > Subject: Boost thread library bugs > > > Here is a summary of several bugs I've discovered over the past few > months in the Boost thread library (version 1_32_0). Sean, please > forward this email to the Boost thread developers. Thanks. > > > > 1) On the PowerPC, the sequence of memory write operations executed > by one processor may be seen by another processor or device in a > different order. This weak write ordering property implies that > when modifying a shared resource, the modifying processor must > execute a sync instruction to make these modifications visible to > all other processors before releasing the lock. I discovered > several situations in the Boost thread library where a sync call is > missing. > > > > call_once: Immediately after the client function returns a lock > variable is set to one. Other processors may see this lock equal to > one before all memory write operations performed by the client > function are completed. A call to __sync() should be made > immediately prior to setting the lock to one. > > > > synchronization class constructors (mutex, read_write_mutex, > condition, etc): Once the class constructor returns, Boost provides > an API where other threads are free to call the synchronization > member functions. However, the memory write operations performed by > the constructor may not have been completed when the member > functions are executed by a different processor. So a call to __sync > () should be made immediately prior to returning from the constructor. > > > > Note that a similar situation occurs between member function calls. > However the MacOS synchronization primitives used by Boost do > perform a sync, so correct operation is guaranteed implicitly as > long the last operation performed by a member function involves an > OS synchronization primitive call. This appears to be the situation > in many places, but there may be places in the Boost library where > this requirement is not met. So someone needs to review all of the > source code for problems of this sort. > > > > 2) On the PowerPC, I have seen situations where call_once deadlocks > in the MPRemoteCall function. I have not been able to diagnose the > problem. Deadlocks occur when call_once is executed by non-main > threads. I believe I have a solution to the problem which uses a > completely different implementation similar to that of the Win32 > version and avoids all calls to MPRemoveCall. Maybe I should submit > this solution to the Boost developers for consideration. > > > > 3) I discovered a deadlock in read_write_mutex. If either of the > alternating scheduling policies are used, the implementation will > deadlock the first reader to arrive when no writers are active. The > deadlock occurs in the function void > read_write_mutex_impl<Mutex>::do_read_lock. If m_state == 0 and > m_num_readers_to_wait == 0 (this holds immediately on > construction), then an arriving reader will hang indefinitely on > m_waiting_readers. There are other related situations where the > BOOST_ASSERT on loop_count fails. > > > > Note I am concerned that such a blatant flaw is present in the > library. This implies that the library has not been very well > tested. This is worrisome especially for a thread library where > threading bugs can be extremely frustrating and hard for uses of > the library to reproduce and diagnose. > > > > -Mike Schuster > > > >

1 0