- Boost - lists.boost.org

[MPL.Math] updates for double
by Cromwell Enage 11 Nov '05

11 Nov '05

I've now added a BOOST_MPL_CFC_NO_MATH_DOUBLE macro that is defined in <boost/mpl/aux_/config/math_double.hpp> when it is known that BOOST_MPL_MATH_DOUBLE won't compile. Please send me your compiler-platform configuration if BOOST_MPL_MATH_DOUBLE doesn't work for you. Peder, The double_::aux::get_value function still returns a number 2^16 times too big on MSVC 7.1 when the input is a whole number. Cromwell D. Enage __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

3 17

Boost regression notification (2005-11-11 [RC_1_33_0])
by Douglas Gregor 11 Nov '05

11 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-11T15:11:40Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 1 failure in 1 library: serialization (1) |serialization| test_contained_class_xml_warchive: vc-7_1

1 0

Boost regression notification (2005-11-11 [HEAD])
by Douglas Gregor 11 Nov '05

11 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-11T06:00:26Z 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. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 167 failures in 13 libraries: bind (1) concept_check (13) date_time (2) graph (3) io (1) mpl (1) serialization (30) spirit (8) thread (8) tr1 (64) tuple (1) typeof (18) xpressive (17) |bind| bind_dm3_test: intel-win32-9_0 |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 vc-7_1 vc-7_1 |date_time| testwcustom_time_zone: mingw-3_4_2 testwposix_time_zone: mingw-3_4_2 |graph| graphviz_test: vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: 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: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: 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 |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_read_write_mutex: mingw-3_4_2 vc-7_1 test_read_write_mutex_lib: mingw-3_4_2 vc-7_1 test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tr1| run_complex_overloads: gcc-2.95.3-linux std_run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.4.4-linux mingw-3_4_2 std_run_random: gcc-2.95.3-linux gcc-3.4.4-linux mingw-3_4_2 std_test_bind: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_boost: gcc-2.95.3-linux std_test_complex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_function: gcc-2.95.3-stlport-4.6.2-linux std_test_hash: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_mem_fn: gcc-2.95.3-stlport-4.6.2-linux std_test_reference_wrapper: gcc-2.95.3-stlport-4.6.2-linux std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_shared_ptr: gcc-2.95.3-stlport-4.6.2-linux std_test_tr1_include: gcc-2.95.3-linux mingw-3_4_2 std_test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_bind: intel-win32-9_0 test_complex: gcc-2.95.3-linux test_hash: gcc-2.95.3-linux test_ios: gcc-2.95.3-linux test_istream: gcc-2.95.3-linux test_iterator: gcc-2.95.3-linux test_limits: gcc-2.95.3-linux test_locale: gcc-2.95.3-linux test_ostream: gcc-2.95.3-linux test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_streambuf: gcc-2.95.3-linux test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_utility: gcc-2.95.3-linux tr1_remove_bounds_test: 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 mingw-3_4_2 vc-7_1 |tuple| tuple_test_bench: gcc-3_4_3-sunos |typeof| data_member_native: cw-9_4 function_native: cw-9_4 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| misc1: mingw-3_4_2 test1: mingw-3_4_2 test2: mingw-3_4_2 test3: mingw-3_4_2 test3u: gcc-3_3-darwin test4: mingw-3_4_2 test4u: gcc-3_3-darwin test5: mingw-3_4_2 test5u: gcc-3_3-darwin test6: mingw-3_4_2 test6u: gcc-3_3-darwin test7: mingw-3_4_2 test8: mingw-3_4_2 test9: mingw-3_4_2 test9u: gcc-3_3-darwin test_cycles: mingw-3_4_2 test_non_char: mingw-3_4_2

1 0

Some notes on TR1 tests
by Peter Dimov 11 Nov '05

11 Nov '05

test_shared_ptr: derived_deleter should take a derived*, not base*. concrete should use virtual inheritance. test_bind: All function tests use bind( &test_proc... ), bind( test_proc... ) should be tested too. -- Peter Dimov http://www.pdimov.com

2 14

[asio] Are the _at_least_n functions useful?
by Christopher Kohlhoff 11 Nov '05

11 Nov '05

Hello all, As part of cleaning up asio's interface I am pondering the utility of the read_at_least_n/write_at_least_n free functions. I'd appreciate hearing from anyone who actually uses these functions (or their async counterparts), and anyone else who has an opinion on the matter :) The rationale for their existence is the use case where you want to ensure that a minimum number of bytes are transferred, but are willing to receive more than that minimum in order to minimise the number of system calls. However I have never used them in practice, and suspect that an application that needed that level of control might prefer to use the lower level (i.e. partial-read/write) functions directly. I'm considering taking them out for now on the following basis: - I want to simplify the asio interface to improve clarity and ease-of-use. - I want to get asio ready for review asap. Including the functionality requires much more thought on how to make it elegant. - asio is obviously useful without them. So essentially I am proposing that the version of asio submitted for boost review does not include this functionality. If a compelling use case emerges in practice then the functionality can be added back after more careful consideration of the design (and with, I believe, no impact on other functionality). If somebody has a need right now, then I'll look at keeping them in, but it will delay getting a version ready for review submission. Cheers, Chris

2 1

cvs access down?
by John Maddock 11 Nov '05

11 Nov '05

I'm seeing strange errors trying to access cvs: cvs update: failed to create lock directory for `/cvsroot/boost/boost' (/cvsroot/boost/boost/#cvs.lock): Read-only file system cvs update: failed to obtain dir lock in repository `/cvsroot/boost/boost' cvs [update aborted]: read lock failed - giving up Anyone else seeing this or is it just me? John.

2 1

[Boost-bugs] [ boost-Bugs-1353854 ] predicates without default constructor fail to compile
by SourceForge.net 11 Nov '05

11 Nov '05

Bugs item #1353854, was opened at 2005-11-11 03:21 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=1353854&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: predicates without default constructor fail to compile Initial Comment: I want to draw your attention to a possible flaw in the implementation of the write_graphviz method from the Boost Graph Library. The current implementation uses the assignment operator for the vertex and edge iterators. This is natural, but some examples fail to compile with this version. The problem comes from the predicates witch don't have default constructors. When trying to assign a vertex iterator of a graph filtered with such a predicate, the compiler issues an error: C2512:'positive_edge_weight_pred<MyEdgeWeightMap>' : no appropriate default constructor available with [ MyEdgeWeightMap=EdgeWeightMapT ] If a small modification in the write_graphviz implementation is made (using copy constructors instead of assignement operators), the example compiles and runs sucesfully. I am using the Microsoft Visual C++ 7.1 compiler. In conclusion, I think that this modification should be made, as it grows the flexibility of the library and doesn't add any overhead. I have attached the example (main.cpp) and the patch for graphviz.hpp (graphviz.hpp.patch). My e-mail adress is pdumitrache(a)bphx.ro ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1353854&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

Proposal: property_tree (property_tree.zip uploaded to vault)
by Marcin Kalicinski 11 Nov '05

11 Nov '05

Hi Everybody, Property tree is a data structure - a tree of (key, value) pairs. It differs from its cousin, "usual" PropertyMap, because it is hierarchical, not linear. Thus, it is more like a minimalistic Document Object Model, but not bound to any specific file format. It can store contents of XML files, windows registry, INI files, even command line parameters. The library contains parsers for all these formats, and more. I tried to make the library as high quality as possible before posting here, so it contains a (hopefully) full documentation, and a comprehensive set of regression tests - more than 300 test cases. By any chance it is not a substitute for (upcoming?) boost XML library - it only supports a fairly narrow subset of XML, and focuses rather on being format-independent. I uploaded it to the vault root dir, file name is property_tree.zip. For more curious, excerpt from the doc: Property tree is a recursive data structure that stores a single data string, and an ordered list of (key, value) pairs, where value is a property tree itself. It therefore forms a tree, hence the name. It is a versatile structure that can store in uniform way data coming from various sources, such as XML or INI files, as well as windows registry, program command line etc. Property tree interface is similar to the interface of a standard C++ container. It supports iterators, insertion, erasing, searching etc. One can think of it as a sort of Document Object Model, which is minimalistic, not bound to any specific file format, designed to be easy to use, and comes as Boost-compatible, headers only C++ library. Many software projects develop a similar tool at some point of their lifetime, and property tree long ago originated the same way. I hope the library can save many from reinventing the wheel. cheers, Marcin Kalicinski

4 7

Re: [boost] New boost webpage
by Janusz Piwowarski 11 Nov '05

11 Nov '05

Rene Rivera <grafik.list_at_[hidden]> writes: > Sam Partington wrote: >> You also need to add this to httpd.conf, otherwise IE will just keep >> on downloading images, over and over and over again, even when they've >> been loaded at page load time. >> >> #this stops background-image flicker in IE >> BrowserMatch "MSIE" brokenvary=1 >> BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1 >> BrowserMatch "Opera" !brokenvary >> SetEnvIf brokenvary 1 force-no-vary >> ExpiresActive On >> ExpiresByType image/gif A2592000 >> ExpiresByType image/jpeg A2592000 >> ExpiresByType image/png A2592000 > > Unfortunately that level of server setup is beyond our control. We can > only hope that SF has such configuration already present on their servers. I see background image flickering is still a problem. I've discovered that you can put above lines to .htaccess file. Regards, Janusz

2 3

[Bind] TR1 and overload ambiguity.
by John Maddock 10 Nov '05

10 Nov '05

The following short program works fine for VC7.1, but for several well regarded compilers including Intel-8/9 and gcc-3.4 fails to compile due to "ambiguous overload" errors. It's causing errors in the TR1/Bind concept tests, and I'd like to figure out if it's the compiler or Boost.Bind that's at fault so I can file defect reports with the compiler vendors if necessary. Here's the test case: #include <boost/bind.hpp> template <class Functor> void consume(Functor f); double test_proc(int a, char b, long c) { return a+b+c; } struct from_double { from_double(double){} }; int main() { consume(boost::bind<double>(&test_proc, 0, 0, 0)); consume(boost::bind<float>(&test_proc, 0, 0, 0)); consume(boost::bind<long double>(&test_proc, 0, 0, 0)); consume(boost::bind<from_double>(&test_proc, 0, 0, 0)); } And a typical error message from Intel-9 is: $ icl -GX -c -Ic:\\data\\boost\\develop\\boost bind.cpp Intel(R) C++ Compiler for 32-bit applications, Version 9.0 Build 20050912Z Pa ckage ID: W_CC_C_9.0.024 Copyright (C) 1985-2005 Intel Corporation. All rights reserved. 30 DAY EVALUATION LICENSE bind.cpp bind.cpp(21): error: more than one instance of overloaded function "boost::bind" matches the argument list: function template "boost::bind<R,F,A1,A2,A3>(F, A1, A2, A3)" function template "boost::bind(R (*)(B1, B2, B3), A1, A2, A3)" argument types are: (double (*)(int, char, long), int, int, int) consume(boost::bind<double>(&test_proc, 0, 0, 0)); ^ compilation aborted for bind.cpp (code 2) Note that it's the presence of the function pointer overloads that causes the error: in other words it's an artefact of the implementation that causes the error, not the TR1 specification itself. Anyone any ideas whose at fault here? Thanks, John.

3 8